This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
… found at build-time.
It was working on a machine with default paths and system-installed
packages (e.g. a typical Linux distributions) but needs to be manually
set up e.g. on Windows.
In particular, we don't want the build to succeed when various obvious
issues occur, which may even end up in a successful-looking build (yet
with no proper language lists), like we had in !1597.
Unlike the GimpTranslationStore which can use a list of pre-localized
languages (each language in its own name), the GimpLanguageStore must be
displayed in the currently used locale.
Our GimpTranslationStore contains self-localized names of all languages
we support.
As for GimpLanguageStore, it contains all known languages with their
name in the current locale. When moving to ISO 639-3 list, we had all
possible language, included ancient ones, extinct ones, and so on. With
the iso-codes installation on my machine, this meant a struct with 7910
languages! When showing the Text tool options for the first time, GIMP's
UI is frozen for a few seconds because of this, while it constructs the
GimpLanguageEntry making use of the GimpLanguageStore.
By only listing part 1 and part 2 languages (as well as the rare
languages which are not in these list yet which we still support, i.e.
right now only 'ckb' (Central Kurdish), see #11626), the list lowers to
189 languages, which is still good and are the main languages or
language families AFAIU. And now the Text tool options are constructed
instantly.
Note that this is in fact even less than when we were just using
iso_639.xml (I counted 487 languages stored there), but I believe it to
be enough for the usage we have in the Text tool.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
Jehan