10.5 Multi-Lingual Requirement Pattern

10.5 Multi-Lingual Requirement Pattern

Basic Details

Related patterns:	Extends multiness
Anticipated frequency:	Zero or one requirement
Pattern classifications:	Pervasive: Maybe

Applicability

Use the multi-lingual requirement pattern to specify that the system is capable of displaying its user interface in more than one alternative natural language (for at least one class of user, though not necessarily all). Also use it to specify that the system can produce output (for example, printing letters or generating stock emails) or accept input in more than one language.

Discussion

Most of what's involved in specifying multi-lingualness is said in general terms in the multiness requirement pattern, which this pattern extends. This pattern is here to make specifying multi-lingual requirements easier and to point out some specific considerations.

Decent support for more than one language is a lot of work; it's not just a matter of creating an extra set of Web pages for each language. Don't ask for it just because it sounds impressive. Only require it if it's essential.

Other variations often go hand in hand with language differences, such as date and number formats. Some of these differences have a geographical element rather being than simply language dependent, and the word locale is used for a geographical region for which specific characteristics of this kind can be defined. Multi-locale is therefore perhaps a more accurate name for this requirement pattern, but multi-lingual makes more sense because this meaning of "locale" is unfamiliar to nontechnical readers and because the multi-lingual aspect is usually by far the most complicated. See the unparochialness requirement pattern earlier in this chapter for a list of factors that vary geographically in this way.

Multi-lingualness can be used for "dialects" as well as distinct languages-for example, American/British English and phraseology for different age groups. Having the system use substitutes for missing resources is especially effective in such cases, because for a dialect you need create only those resources you genuinely want to be different. Everything else works fine and can be expected to make sense to the user.

Consider cultural differences and national sensitivities, too. Is each language version simply a direct translation of another, or should we do more? What's acceptable in the home culture of people who speak one language can differ from what's acceptable somewhere else. This applies to text and images and other kinds of resources.

The international standard that defines codes to use for languages is ISO 639.

Content

A multi-lingual requirement should contain:

1. Extent of support How much multi-lingual support do we need from the system? Asking for a multi-lingual user interface for only one class of users can dramatically cut the amount of work. Consider each class of users separately. Typically a multi-lingual support is delivered to customers only, and poor employees must make do with one language only.

2. Expected number of instances How many languages are we likely to support? If we're planning to support dialects, state a separate number for them because they're less work and less risk.

3. Limitations How can we make implementing multi-lingualness less onerous? If we can do without support for languages with multi-byte character sets (such as Chinese and Japanese), say so. Similarly, say so if we don't need to worry about languages that are read right-to-left (such as Arabic).

(This is a tailoring of the content described in the multiness requirement pattern just described.)

Template(s)

Open table as spreadsheet

Summary	Definition
Multi-lingual [«Scope qualifier»]	The system shall support multiple languages. «Statement of extent». [«Number of instances statement».] [«Limitations statement».]
Provision [for «Scope qualifier»] to become multi-lingual	The system shall make provision for the future introduction of support for multiple languages. «Statement of extent». [«Limitations statement».]

Example(s)

Open table as spreadsheet

Summary	Definition
Multi-lingual customer user interface	The system shall allow the customer user interface to be available in multiple languages. Each customer shall nominate which of a range of supported languages they wish to use, and then every piece of information displayed to them by the system shall be in that language. This shall include screen prompts, messages, and graphics, audio, and video that contain language-specific content. It is anticipated that no more than three languages will be supported. Languages that use a multi-byte character set need not be supported. This requirement does not apply to the user interface of functions used only by employees (which is needed in one language only).
Provision to be multi-lingual	The system shall make provision for the future introduction of support for multiple languages. Provision shall include at least the following: The structure of the database shall be such that multi-lingual support shall not necessitate the addition of columns to tables or the replacement of any table by one or more others. A user shall be able to nominate their preferred language when entering their personal details.

Extra Requirements

All the types of extra requirements in the "Distinct User Experiences" subsection of the multiness requirement pattern apply to multi-lingualness.

Here are a couple of specific examples:

Open table as spreadsheet

Summary	Definition
Default language	The system shall have a default language. The user interface shall be displayed in this language unless and until a user chooses an alternative preferred language from among those supported. A Web address can have a language associated with it, and visiting such an address shall constitute choosing that language. (For example, visiting "«Home URL»/fr" might choose French.) Every element of the user interface shall be present in the default language.
Substitute missing language resources	If a language-specific resource is missing (not present) for a particular language, the equivalent resource for the default language shall be used instead. This shall apply for any type of "resource" displayed in a user interface: Web pages, messages, pieces of text, images, and multimedia resources. An error shall be logged (with low severity) whenever a substitution of this kind is made. The motivation for this requirement is resilience: to display the best user interface even when some of the resources it needs are missing.

Considerations for Development

Take inherent multi-lingual capabilities into account when deciding which technologies to use, especially if you must support languages that use multi-byte character sets.

There are also a small number of considerations in the multiness requirement pattern.

Considerations for Testing

Involve someone who can speak each language being tested. For proper independent testing, don't use a person who participated in translating or otherwise producing the resources for that language.

See also the considerations in the multiness requirement pattern.