Problems we need to solve
Translation
Launching a multi-lingual product is usually a basic requirement of a global product. Localization deals with the complexity of turning the original development language (say English, for simplicity) into the desired target languages we want our product available in. The goal of internationalization is to organize all English strings in such a way that can be translated and replaced with translated strings produced by the localization process. The complexity comes from the different linguistic requirements of different languages and the need to let go some of our assumptions driven by the linguistic rules of the source languages.
In particular:
- Translation needs to happen at the full sentence level. Any programmatic assembly of sentences possibly makes it impossible to localize correctly in certain languages. This is a particularly big challenge when sentences are not fixed but parts of it need to vary dynamically (e.g. they contain the name of a user, a number, price, date).
- Plural rules vary by language.
- Additional mixed-script challenges (especially for RTL languages)
Language manipulation Complexities
Word tokenization (no spaces), case (turkish ï), diacritics, sorting/comparing (binary vs. logical), initials (names, index, tabs), directionality, security (login case)
Numbers and Currencies
At the very minimum decimal separators are important to get right. Group separators also vary ("1,000" vs. "1.000" vs. "1 000" vs. "1'000") and group rules also vary ("5,00,000" or "5 lakhs" in India).
Numbers can be written using different numerals (like Arabic and Japanese).
Currencies extend from numbers and may include currency symbols (which need to be localized)
Date and Times
Conceptual dates and date ranges (e.g. date picker) vs. instance in time (how to represent it internally, like ms from epoch and ISO format). Different calendars (japanese, thai). Time zones (IANA). 12/24 hours (and beyond).
Other Regional Complexities
There are too many to mention and some are very product-specific, so it's important to investigate what may have to change because of the region or the languages. For example:
Measurement systems: gallons vs. liters, miles vs. kilometers, pounds vs. kilograms, Fahrenheit vs. centigrade. But common usage may be more complex that a simple arithmetic conversion. For example, if in Europe the height of a person may be entered as a single number in centimeters (e.g. "180 cm"), in the US a single number in inches is not very common and a split feet/inches format may be more common (e.g. "5 feet 11 inches").
Postal addresses. The order, name, and number of components of a postal address vary country by country and script by script. For example, not all countries have zip/postal codes, and those that do usually have widely different formats and validation rules.
Phone numbers. The formatting and validation rules of phones change by both region and phone carrier sometimes (e.g. mobile vs. landlines).
Computer systems: regional differences may impact usage and localization of software. For example keyboard layouts vary widely and may require adjusting some affordances like shortcuts. Fonts have to be selected that support the required scripts.
Other cultural considerations:
Politeness. Using first vs. last name. Using honorifics.
Imagery. Using regionally-appropriate images (especially in marketing images) and icons.
Color schemes. Some colors have different/strong connotations in some cultures.
Information density. Expectations may differ (simple clean UI with multiple steps vs. all options in one crammed page).
In addition, there may be many region-specific product differences because of regulatory compliance or simply as a product management decision. For example:
- Requirements around what data can or should be collected for each user.
- Enable/disable a feature based on a region (partial feature launch by region)
- Enable/disable a feature based on availability of another feature (e.g. if payments are enabled)