Notes on Building a MultiLingual RIA
- RIAs must validate on both the client and server-side. Thus, the server must have access to validation data. In that regard, it is easier to have the server handle the language-sensitive validation and then send it to the client, rather than have all language-sensitive elements (prompts, messages, validation) at the client.
- Application common validation should be allowed. For example, allowing a dash in names - which may not be considered part of an alphabet should be consistent for all supported languages.
- Localization is a separate issue. It can be addressed in many different ways. The amount of time spent on localization should be carefully considered. For a limited audience RIA, localization may be addressed with screen prompts and documentation which allows users unfamiliar with the formats to work with them. This approach is suitable if the localized elements are limited or the user is unlikely to use them often. For pages that will be used frequently, localization should be considered. Localization should be consistent throughout the application, meaning if one page is localized, or one type of data is, all should be.
- Language strings can be stored in the database or in files of name/value pairs. They should be constructed in such a way that word order can be adjusted for language, this may mean more strings or multi-word strings.
- Language resources should be dispersed such that pages only retrieve the data necessary to support the active page.
- Some parts of the application may be based on the native language of the server. This should be supported with documentation.
- If it is likely an application will be multi-lingual, it should be built in from the beginning, it will greatly increase the cost of development to change a single language site to multilingual if it wasn’t built with language independence.
- Frameworks and toolkits like Zend Framework (http://framework.zend.com) and dojo (http://dojotoolkit.org) have execellent resources. It is much better to use these as starting points than to try to reinvent the wheel.
- Report files and any emails should also be multilingual. Ideally, these should draw language data from the same source as the application.
- Log files need not be multilingual.
- Templates should be language independent.
- Images should be language independent, or language sensitive versions should be developed.
- Flags are an excellent way to allow selection of language.
| Print article | This entry was posted by elvis on 02/16/09 at 08:01:41 pm . Follow any responses to this post through RSS 2.0. |