Internationalization

Problem Summary: iMIS needs to be translated into multiple languages and used in a number of countries
Pattern Key: I18N
Example: None
Use When: Always
Solution:
  1. Except for currency, all localization is based on an iMIS setting for each website.  This includes language, date format, etc.  The browser locale should be ignored.
  2. Currency is determined by price sheets. 
Rationale: Need to be able to sell iMIS in multiple countries
Accessibility: NA
Internationalization: NA
Supporting Examples: None
Where Used: Everywhere
Coding: BOD lets you specify a resource key for the prompt.  Use this instead of the actual word.

Items of Note: None

Put to Use

Status: Partly created

Adherence Rating: Required

Used in Conjunction with: None

Related Patterns:

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Multiple languages for iMIS

Where did a requirement for multiple languages come from?
The cost of translating the help files is staggering and even reshaping the screens for labels in another language is substantial.
The first language needed is French that is required in bi-lingual Canada where we have substantial sales, but we have always been unwilling to let the Quebec tail wag the English speaking dog.
It is my hope that some of the side effects of our normal development (such as the Screen Painter and Reporting Services) will lower the costs of making the legally mandated changes for Canada, but doing another language (such as German or Chinese) is something that only a much larger company can allocate scarce resources toward.

Enable Translation

These patterns are to guide development. The purpose is to document for developers what is needed to enable translation, such as making sure that all messages are in resource files. Which translations are actually done is decided by someone else.

Our goal is to reduce the cost of such translations, as you suggest. Do you have specific suggestions about how to reduce the cost of the changes required in Canada?

I18N is not necessarily/just translation

There's a subtle difference between Internationalization ("I18N") and Localization ("L10N") (wiki). I18N involves readying a software product for use in various languages/cultures/locales, which means ensuring, for example, that not only can viewable strings can be translated eventually, but that things like date/time formats, currencies, units separators in numbers, etc., are appropriate to the culture of the viewer of such data. L10N is the actual generation of the resources necessary, mainly in the area of translation.

I take this thread to mean that where possible, we develop code with I18N in mind, to avoid extra expense in retrofitting non-I18N code prior to actual L10N efforts.

My USD 0.02... ;)

Multiple Languages for iMIS

Thank you both for pointing out the i18n standard. I was focusing on the translation that had always been a dream of Sales but has always been dashed by the reality of translation costs. Yes, if it does not add substantially to our development costs, we should follow these standards and isolate text from code. Doing these things from the start (like accessibility to conform to the Rehabilitation Act) is always much less extensive than trying to comply later.
As far as Canada goes, we have much less lofty goals there. We need to present web sites in both languages and certain reports (such as Dues notices) in two languages. The real experts on those requirements are Andy Sherwin and the Consultants in ASI-Canada.
Personally, I have problems just localizing the License Agreement (Licence Agreement outside of the US).

Expansion in Translation

What, if anything, do we need to do to accommodate translations that are longer than the English version? (The English is almost always the shortest.)

In many cases, the browser will automatically expand and handle this. In what circumstances is this not enough? Can anyone suggest a reference?