Localisation - Internationalization Package

[R.H.]

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