Being "international" I also have lots of need for localization from German to English, French, Italian, Russian. UTF-8 is my friend, first of all.
For example, in Switzerland, there are four languages and the German part of Switzerland uses different decimal/currency number settings compared to Germany. So, a language-specific locale read from a system does not fully help. It is required to know about regional settings and user settings since some users change the default settings of the OS. By default in LiveCode, only the English/US date and number settings are recognized as valid. A date format such as dd.mm.yyyy would not be a valid date. A bigger problem is that the date can be ambiguous. How to know if a month and day is actually a month or day using mm/dd/yyyy instead of dd/mm/yyyy? You need to know the source of the date string to be able to convert it to the local settings in such cases. And no system will tell you that. If you can not read the setting from the OS regarding locale specific week day names, month names, etc, the only way is to provide them in your LiveCode application yourself. For me, the English always is my system language. So, providing the English name as the key parameter will always generate the associated language text. A function calls the array which stores the language-specific week/month or whatever name. When dealing with such situations, there should be an internal/system storage and an external presentation layer. As in Excel, a date can be formatted the way you like and presented, but internally it should be saved and managed in a way that is presentation-independent. For translations, I never worked with YAML files and I have to look at how that would work. (More information may be interesting.) I am using arrays that can be saved as files and be loaded, even put into a database such as MySQL. It is easy to name controls in LiveCode and change their label looking up the path to the control and changing the label name to be language-specific. When the user changes the language, all labels are changed immediately. The same is true for the text in fields that can also easily be changed the same way. For any dialogues (ask, answer, ...) I am using an English abbreviation that is uniquely identifying a dialogue. It helps to identify a dialogue by name. So again, the actual text of the dialogue is associated with this unique key, and the translation can be found in the associated array combining the key and the language code (de_ch for German in Switzerland, de_de for German in Germany -- they quite different). The same I do with all error messages that are visible to the user. They are passed to a handler which looks up the language-specific text. Even though I like defaults taken from the OS system settings, they may not apply to individual users. A US citizen may travel to Europe and use a computer with a European locale. What to do? I always give the user the choice to select what the user wants to see. So, there is no way around having your own layer of settings for translations, number format, date formats, etc. Since setting up such a locale-aware system is still a lot of work, I would find it helpful for international users of LiveCode if we had such an Internationalization Package to ease the work. Best practice should be applied. It is not as trivial as it may look at first. There are many ways of achieving the same aim using LiveCode, but a standard way of doing things would be more helpful to everybody. If you plan internationalization, then the best is to start setting it up before you actually do the application specific work. -- Think of languages you need -- Think of date formats (language independent) -- Think of number formats (language independent) -- Think of other regional specifics One consideration is that it is best practice storing values always only once (as defined in Normalization rules of SQL databases). For example, working with decimal numbers and their formatting, never use the displayed format for calculations, but only the internal number format. The internal number value is the only valid value. The displayed value is calculated value always. For example, how will you add numbers formatted as "10.000.000,00" as used in many European countries if you do not store the actual value as a text-string of the number in the form of "10000000.00" internally? (You could, of course, convert such number/date strings all the time, but it would end up in more processing time used, and ambiguous number representations for export/import or any outside-dealing with data. Using several formats can mess up your whole application.) The system looking up values or settings must be extendable and flexible, never hard-coded. If the user changes the language, number formats, date formats, the system should automatically respond if such settings are supported. It should then not only present the new settings, but also allow the user entering values according to the preferred settings. So, my advice is to think about a layer that represents computer readable data (we use text in LiveCode that also C language understands) and a presentation layer with user-specific language dependent and locale-dependent data. When users enter data, such data is converted to internal data. When presenting data, it is presented as local-specific data. The basis of data formats and their storage must always be system-internal data representation that computers understand (including applications such as LiveCode -:))) to avoid any kind of ambiguity. And for international LiveCode coders: Since English is the Lingua Franca and nobody can change this, I would also recommend commenting code and all internal work using English only. If that is not possible, ok, but it is preferred. (I do not recommend translating LiveCode script as such. I do not like it in Excel when using language-translated formulas, and I do not like it in FileMaker scripting. There is not so much to learn for serious developers using this little bit of English for programming. Musicians have to learn their notation language as programmers have to learn their computer English.) A good translation engine you find using https://www.deepl.com. It can even be hooked to your system offering such translation service "on the fly". It is considered independent of Google and better. But it does not support all languages as Google & Co. does. It is based on an Artificial Intelligence system. Roland _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode