This chapter describes what is meant with language switching, why it is needed, and what impact it has on software development.
When designing and implementing software, also language switching must be kept in mind.
If the application is merely for one region or language, it should be considered how language switching will carried out. Will the application be available in the other device languages or not? If not, it should be possible to disable the application or feature in other languages that our customers will include in a device. This should be clarified by the relevant Requirements Manager. A practical example would be whether Chinese lunar calendar should also be available in the English UI? If yes, is there enough space for text items in the English layouts (Chinese words can often be presented with one character only)?
There are also features that are available only for certain language variants. For instance, number grouping for phone numbers is available only for the US English variant, and pictographs are only available for the Japanese variant. These features can also often be operator-specific at the same time.
It should also be considered how the user-defined data is stored and made available for the application or feature after language switching, or whether it is available at all. For instance, if a user has selected colon as a time separator in English, what will happen when s/he switches the UI language to French? Will the separator also be applicable in the French UI or should it be according to the French custom? The automatic naming of files must allow for localization. For instance, "Image01" must be localizable, that is, a logical name is needed.
It should be noted that S60 does not support dynamic UI language switching; that is, the device needs to be rebooted to have the UI language switched. For input language, dynamic languages have always been possible in S60.