I18nstd » History » Revision 2
Revision 1 (Shuvam Misra, 09/11/2023 06:26 PM) → Revision 2/6 (Shuvam Misra, 09/11/2023 07:56 PM)
# I18N There are many dimensions to internationalisation (i18n) of software systems. It is often equated to support for multiple languages on UI screens, where this is just Level 1 of i18n support. The dimensions, from the most obvious to the less obvious are: 1. multi-lingual support for labels in screens and reports 1. adaptive screen layout for R2L and CJK contexts 1. multi-lingual support for data input, with validations, multi-lingual search strings 1. multi-lingual support for data output and display, again with R2L and CJK support 1. multi-timezone support for all timestamps and separation of effective date of transactions from system time 1. multi-format support for dates (including month names), times, numbers and money amounts 1. multi-currency money values The scope of full i18n is as described above. Our current standard only specifies how our applications support Item 1 in the list. ## Multi-lingual labels label standard Labels are all instances of fixed text in the software, which does not change when the data in the system changes. For instance, the **Name:** text before the name input field, or the **LEDGER** heading in a table in an accounts-receivable report is a label. To support multi-lingual labels, In Alya, there will be a two-tier structure. 1. **Tier 1.** A spreadsheet master file which will have one worksheet per language. In that worksheet, there will be one row per message, and the first column will be the English version, the second will be the "other language" version. So, if we support 20 languages, there will be 20 worksheets in this file. contain 1. **Tier 2.** * a string ID * a hashmap of `(langcode, string)` key-value pairs From this spreadsheet will be auto-generated generated language-specific files using a set of JSON files, one per language. We tool. Each language-specific file will have a tool which will read contain just the spreadsheet string ID and auto-generate all the JSON files. its corresponding string in that language. The master file format will be ``` json { "1": { "en-IN": "Invalid name", "hi-IN": "(something in Hindi)" }, "2": { "en-IN": "Invalid address", "hi-IN": "(something in Hindi)" } } ``` The language-specific file will have the format ``` json { "1": "Invalid name", "2": "Invalid address" } ``` The name of the language-specific file will be of the form `XYZ-en-IN.json`, where the `XYZ` will depend on the application. All the language-specific files for a given prefix of `XYZ` will have the same filename format, and will carry the same set of keys, with strings in different formats. One But an application may have multiple sets of files, *e.g.* an `XYZ*` set of language-specific files, another `PQR*` set of files, and so on. They will be generated from their respective master files. The keys within a single file will have to be unique, and the set of keys in all the language variants of a set will need to be consistent and uniform -- it is not acceptable to have a key missing for the Hindi file but present in the Spanish file.