The localization system should be able to select an appropriate string by key, from a set of resource strings, that is translated for one of the supported locales.

To support the possibility of all strings for all UI components for all locales being present within the same database (possibly as a side effect of a certain translation work flow processes, the key used to identify a string may contain the following parts...

The localization system should support substitution of values into an arbitrary number of tokens inside resource strings.

Furthermore, the substitution system should support values being of specific types which can inform formatting of their values and provide cues to a string variant sub-selection mechanism that can select available variants that best match the qualities of the substitution values.

In cases where genders and/or quantities need to affect the translation of a resource string for a specific language, the localization systems needs to support the sub-selection of the best string variant.

Since string variants may not be necessary (and may not exist) for all languages, the string variant sub-selection mechanism should support a system for fallbacks, such that a more generic variant is selected unless a more specific variant is defined. To allow the desired priority to be controlled, a simple algorithm can be employed that iterates through all the defined variants and selects the last matching variant, leaving it up to the author of the translations to order the variants from most general to most specific.

1.1.3.1. An Example

1.1.3.2. Pluralization

The localization system should support formatting a number correctly for the locale.

Most locales, for example, will require a "." (period character) to be used to indicate the decimal point, while some specific locales will require that a "," (comma character) be used.

Properties of locale specific number formatting...

Certain numerical types, such as currency values, percent values, measurement values, etc. have special formatting considerations that differ by locale.

The localization system should support formatting of currency values appropriately for a locale.

Formatting a currency value correctly involves a combination of using the appropriate currency unit symbol and placement, along with the appropriate number formatting for the locale. It is not the responsibility of the localization system to perform currency conversion based upon prevailing exchange rates - that can remain the responsibility of the application.

In the case of substituting currency values into resource strings, it should not be the responsibility of the code providing the currency value substitution to perform pre-processing of the currency value in order to format it, but ideally the currency value provided to the substitution mechanism would be of a type that would cue the resource string processing code to invoke the appropriate formatting before value substitution. Either the value type can be provided to the resource string processing code, or the value type for a particular token could be explicitly provided in a descriptor for the token, as in...

amountPaid: The amount of {paid:currency} has been debited to your account.

The localization system should support formatting a date correctly for the locale, including the appropriate translations of day and month names.

As with currency formatting, when date type values are substituted into resource strings, it should not be required that the code providing the date value perform any pre-processing, but the substitution mechanism should be able to perform formatting of the date value as needed as part of producing the translated string.

joinDate: You activated your service on {activationDate:date}

Optionally, formatting cues may be provided - either as ancillary data that is provided along with and as part of the date value, or as an additional descriptor for the token in the resource string.

joinDate: You activated your service on {activationDate:date,short}

Additionally, the localization system should support the following type formatting...

The localization system should provide support for localizing measurement values for a locale, which may involve converting the measurement values from values expressed in a canonical system of units, such as the SI / metric system, to measurement values expressed in a system like the Imperial System.

1.1.9.1. Imperial vs Metric

1.1.9.2. Unit Symbol Localization

The localization system should support string collation (sorting), taking into account how ordering rules apply to the character set in use by the language.

Sort orders such as alphabetical or ASCIIbetical are not meaningful for the writing systems for certain languages, such as Japanese kanji, and a different type of collation algorithm needs to be applied. The localization system can provide collation as part of a service API, considering that collation for certain languages can be complex and have a performance cost that is not desirable for a client device.

The localization system should provide the client with cues to indicate whether sorting can be performed on the client side with a simple algorithm or whether sorting should be offloaded to a service, and the client code should be written to anticipate that sorting might be a process involving an asynchronous service.

As far as RTL (right-to-left) layout is concerned, the localization system should support at least the ability to determine whether an RTL layout should be used for a specific locale.

Once it is known that RTL layout should be used for a locale, it is the responsibility of the UI framework to invoke RTL layout and the responsibility of the various UI components to implement support for RTL in their styling.

The UI framework should support selection of styling code based upon the locale information queried from the localization system.

Style conditionalization can be performed in either (or both) of two ways…

The localization system should facilitate the conditional selection of media appropriate for a given locale.

At the very least, the localization system should provide the necessary locale information to inform conditional selection of media, but the system may also provide a framework for defining locale specific overrides for media along with a system for selecting a best match for media for a given locale, with a fallback heuristic to address situations where very locale specific media variants are not provided.

The localization system should provide an application the locale information necessary to allow it to tailor its content to be most suitable for any given locale.

1.1.14.1. Content Filtering vs Content Ranking

The localization system should provide an application the locale information necessary for it to determine which features of the application should be enabled and which should be disabled.

It is not the responsibility of the localization system to resolve feature configuration for a specific locale - this is the responsibility of a separate decision engine that will likely accept multiple input parameters to allow multi-dimensional configuration. That is to say, whether or not a particular feature is enabled may be determined by multiple different factors, one of which may be the user's locale (or data derived from the user's locale). In this sense, feature configuration is similar to locale content tailoring.

It should be possible to switch the locale to be used throughout an application on the client.

It should be possible to server an application to users in multiple different locales from the same server.

To this end, it would not be a viable solution to build the set of localized assets for each of the supported locales while keeping the URIs the same - the URI for each localized asset would have to be different per locale, which also means that the client would have to request the appropriate localized version of an asset for the client's locale. Not encoding the locale into the path of the URI for a localized asset would leave only the option of serving the localized assets for different locales from different domains and, while there may in many cases be domains dedicated to certain of the major locales, it cannot be assumed to always be the case, Furthermore, it may be desirable to serve all the static assets from a central CDN with a common domain, even while the application may be served from locale specific domains.

To increase the productivity of those doing translation for of resource strings along with those doing visual testing of localized UI, it should ideally be possibly to switch between locales without incurring a costly full reload of the page or app.

All UI components would ideally be implemented to allow updated resource strings to be dynamically propagated into the UI, and the app environment would support the ability to switch locale and have the necessary resource strings for the new locale be loaded for all the localized UI controls.

Live locale switching would ideally be supported at a UI component level, with the ability to use a locale switcher for an individual component. When a component is switched to a new locale, all of its child components and their child components (i.e. the entire component tree beneath it) should be switched to the new locale as well.

In order to enable more responsive tools for translating resource strings and instantly previewing the translations in the UI, the UI framework's localization mechanism should ideally support dynamically updating the UI as resource strings are modified.

Given such a live updating mechanism, translators can then visually preview their translations and correct layout issues immediately by making choices between different candidate translations to achieve the best layout for the language they are translating for, rather than having problems slip in and only be discovered during localization QA testing or - even worse - once the code has already been pushed to a production environment.

While it is desirable to compose resource strings into the presentation as part of a runtime rendering process, it is sometimes not possible to render all parts of the presentation dynamically.

In cases where it is necessary to localize media assets that cannot be rendered dynamically, because of performance issues or a lack of the rendering technology in the client, it is desirable to have a system in place to allow for rendering of templatized media of various types, either as part of a build process or as an ob-demand process that is load optimized through a type of caching facility.

An alternative to a media template processing system is to rely solely on media conditionalization with the job of rendering templatized media being the responsibility of production processes of a creative department. This can work at a small scale, but becomes increasingly burdensome as product complexity and supported locales increase. A manual production process also does not lend itself well to an integrated translation process.

For any UI component system, whether implemented for Web technologies or native operating system frameworks, certain inheritance characteristics should be supported.

1.3.4.1. Inheriting Locale Strings From a Superclass

1.3.4.2. Overriding Inherited Locale Strings

1.3.4.3. Declaring Additional Locale Strings

Because it is not possible for a UI component's code to know what locale the code will be run in, expressing a dependency on a set of resource strings can only go as far as providing a base guide, where the runtime environment will determine what exact module is required based upon the locale set for the environment at the time of loading the UI component.

Canonical values don't exist for currency values in the same way as they do with linear dimension values, for example.

Conversion between different currencies must involve a central monetary exchange service that is aware of the up-to-date intercurrency exchange rates - it is not possible to implement static code as part of an internationalization utilities library that can perform conversion for the purpose of display.

Therefore, a currency value type should always carry the currency for the value independent of the locale setting for the application.

There is not a one-to-one mapping between locale and currency.

Certain locales may have an associated currency (or currencies), but it can't be assumed that there is a specific currency for a specific locale. Panama, for example, supports both the US Dollar and the Panamanian Balboa.

In cases where the appropriate currency can't be determined from either the locale in which the application is offered or the locale of the user, the application may wish to make the currency selectable by the user, and the application may also wish to display monetary amounts in two or more currencies. A traveler in the United Kingdom, for example, may have a combination of Pund Sterling and Euros in their wallet and it may be convenient to see amounts in both currencies, with the secondary / non-dominant currency shown in a separate column or in parentheses.

Number formatting and currency formatting can be distinct from one another and should not be conflated.

For example, in an application that displays amounts denominated in Euros in Germany, there would be an expectation for the correct Euro currency symbol to be used as well as the appropriate use of the period character to delimit thousands and the comma character to indicate the decimal position.

AMOUNTS DISPLAYED IN GERMANY

€ 1.234,56  (US $1.973,04)

In contrast, if a Euro-denominated amount were to be displayed as a comparison alongside a US dollar amount to users in the US, there would be an expectation for the thousands in the Euro amount to be delimited using commas and the decimal place indicated by a period.

AMOUNTS DISPLAYED IN US

€ 1,234.56  (US $1,973.04)

A type that inherits from a more basic type, such as a currency type that inherits from the basic number type, should inherit the display options from that basic type.

So, a currency type would allow display of grouping to be specified as a serialization option, but would also extend an option for display of the currency type (either the currency symbol or the currency code).

When a resource string expects substitution values, the type for every value expected by the string should be specified.

4.2.1.1. Specifying Types Should be Required

4.2.1.2. Casting Types

Your enrollment was approved on {approvalDate:Date} ({approvalDate:TimeAgo})

When a token is defined for a resource string in the master resource strings file, any serialization options defined for the token should be inherited by the locale specific translations of the resource string, but should also be overridable for specific locales.

For example, for a specific string it might be decided that it is desirable for a date token to use the long option for month when formatting the substituted date values. Then, for a specific language (such as German), it might become evident during testing in German that the layout does not have sufficient room to accommodate long month names, so the narrow option could be specified explicitly for the token in the German translation.

A substitution token may be used more than once in the same string, and it should not be assumed that every occurrence has the same formatting options.

As such, different formatting options may be applied for different occurrences of the same token in a string, or the value may even be cast to a different type in a specific occurrence.

The recommended BCP 47 format locale code to use for pseudo-localized resource strings is "en-ZZ".

BCP-47 does not address pseudo localization and, as such, does not provide any specific guidance on how to deal with locale codes for pseudo localized resource strings.

It does, however, leverage the ISO 3166-1 standard for region codes, and this standard allows for a limited set of user assigned region codes that are reserved for non-standard use. These ranges of codes can be used for any internal / proprietary use.

http://en.wikipedia.org/wiki/ISO_3166-1#Reserved_and_user-assigned_code_elements

Based on this provision, it is recommended that the locale code that is used to represent the pseudo-locale be a BCP 47 format locale code, so that the pseudo-locale code is fully compliant and doesn't risk any collision - now or in future - with language codes and region codes for real languages or regions. Although three letter region codes are acceptable, it is recommended that a code that lies within the two letter range for user-assigned region codes be used. This is for the sake of simplicity and consistency with the prevalent use of two letter region codes for other locales.

Based on the ISO 3166-1 standard, there are a few candidates for pseudo locale region codes that should appear to developers to be be obviously intended for a special purpose (pseudo-localization, in this case)...

Out of this short list, the "en-ZZ" is the most appealing, since it stands out as probably having a special meaning (in case you see it for the first time), and it sorts to the end of the list of regional variants of English.

It is recommended that the resource file format should be a pure data format, completely devoid of the capabilities of the programming language used by the application that will use the resource strings.

8.1.1.1. Prevents Undesired Dependencies

8.1.1.2. Avoids Parsing Difficulties

8.1.1.3. Candidate Formats

In addition to the recommendation that a pure data format be used for resource files, the following additional recommendations are made...

8.1.2.1. A Clean Format

8.1.2.2. Narrowed List of Candidate Formats

The resource file format should allow optional metadata to be supplied for every resource string.

A generic system for specifying resource string metadata can serve a number of different purposes and may be used to capture the following types of information...

8.1.3.1. Resource String Translatability

8.1.3.2. Resource String Type

8.1.3.3. Resource String Context

8.1.3.4. Resource String Constraints

8.1.3.5. Resource String Translation Instructions

Non-translatable strings are resource strings that should not be translated.

Examples of non-translatable strings include...

Even though these strings may not be translatable, it is nevertheless practically useful to store them in resource files along with translatable

If automation scripts that prepare jobs for translation can detect resource strings that are non-translatable, then these strings can be excluded from the translation jobs that are sent to translators. In this way, one can eliminate the cost associated with the translators evaluating these strings for translation, since there may be a baseline processing fee even if a determination is made to leave the strings untranslated.

An additional and even more compelling benefit to knowing which resource strings are not to be translated is that these strings can be left as is by an automated pseudo-localization process, since inappropriately pseudo-localizing some non-translatable strings such as URLs may actually break parts of the functionality in a pseudo-localized version of an application, thereby hampering the efforts of QA testers.