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.
langinfo.h is not on all systems apparently and/or the locale item we
test for may not be available everywhere. Actually even on Linux, after
testing more deeply, I could create cases where nl_langinfo() would not
return a result (if the locale is broken through environment variable
for instance). setlocale() seems to always return usable value so far,
so I fallback on it. As a last resort, I look at environment variables
(even though these may contain invalid contents.
As for Windows and macOS, I try to use more platform-specific methods.
In macOS in particular, as I understood from reports, GIMP follows
correctly the language preference order, which means we should not look
at a single (top) lang, but at the whole list of prefered languages as a
single settings to determine whether the language was changed or not.
Should fix on Windows:
> fatal error: langinfo.h: No such file or directory
and on macOS:
> error: use of undeclared identifier '_NL_IDENTIFICATION_LANGUAGE'
Since localization is fully handled plug-in side now (see #8124), we
need to make sure the query functions are run again for all plug-ins
when the UI language changes (otherwise we might end up with
localizations from the previously used languages).
We were already reloading plug-ins when explicitly changing the lang in
the Preferences, but this new implementation is much better as it's
generic. In particular, it will also handle the case when the system
language changes (or when you play with locale environment variables).
Revert "app: also localize LC_TIME to GUI language."
This reverts commit a4e65ac836.
LC_TIME format apparently does not accept the broader format with just
the lang part, for instance "fr". The region is necessary, like "fr_FR".
In our supported languages, we were mostly using lang only except for a
few langs where we support regional variants.
This makes sense as time format may be quite different depending on
regions (dates are quite different in GB vs US, though that was actually
one of the cases where we were using accurate locale format).
And the main issue is that it was not only breaking time localization.
Normal string localization (LANGUAGE) got somehow broken as well by
broken LC_TIME.
Anyway for now let's just stick to whatever OS-set time format (even
though it may differ from GIMP Preferences-set language defaults).
When we set the GUI language through Preferences, also set LC_TIME, so
that locale-aware date functions also produce the right formats.
For instance, I use this in the About dialog to format the release date
of the last version of GIMP.
If any of the locale environment variables used for UI language is set
(LANGUAGE, LC_ALL, LC_MESSAGES and LANG), do not let Windows' default UI
language override these.
Language set in GIMP preferences still have higher priority.
Jehan