Currently, we use a hardcoded list of languages (with their name in the relevant language and in English) from languages.json for translations. Additionally, we use setlocale() and strftime() for localizing datetimes. Especially the latter is a bit fragile, because the locale name must match exactly and must be available on the system (which requires regenerating locales on e.g. Debian using dpkg-reconfigure locales).
A possible easier system could be to use the PHP intl extension. This supports getting all kinds of information about various locales, allows listing the available locales, allows specifying just the language code and let the extension figure out the rest, allows getting the name of a language in another language, quickly switching between different locales (since you just specify the locale when doing a date format, rather than having a global "current" locale).
I did a quick comparison of the intl-supported locales (using LocaleBundle::getLocales("")) versus the current languages.json. It seems that intl has a number of extra languages, but also misses some (such as aa). However, it does seem that it knows about the languages (i.e. Locale::getDisplayName("aa") returns something meaningful), it just does not have the info for e.g. formatting dates in this language). This is also confirmed by this list: https://www.localeplanet.com/icu/iso639.html Since you can easily translate pages into languages for which no localization is available, using intl to replace languages.json for a list of languages to translate into might not be ideal (it seems the underlying ICU library does have a getISOLanguages() function, but it seems the PHP wrapper extension does not expose that).
Still, using intl for e.g. date localization (and probably other things too, like string sorting or comparison) might be interesting to explore.
Currently, we use a hardcoded list of languages (with their name in the relevant language and in English) from languages.json for translations. Additionally, we use
setlocale()andstrftime()for localizing datetimes. Especially the latter is a bit fragile, because the locale name must match exactly and must be available on the system (which requires regenerating locales on e.g. Debian usingdpkg-reconfigure locales).A possible easier system could be to use the PHP intl extension. This supports getting all kinds of information about various locales, allows listing the available locales, allows specifying just the language code and let the extension figure out the rest, allows getting the name of a language in another language, quickly switching between different locales (since you just specify the locale when doing a date format, rather than having a global "current" locale).
I did a quick comparison of the intl-supported locales (using
LocaleBundle::getLocales("")) versus the currentlanguages.json. It seems that intl has a number of extra languages, but also misses some (such asaa). However, it does seem that it knows about the languages (i.e.Locale::getDisplayName("aa")returns something meaningful), it just does not have the info for e.g. formatting dates in this language). This is also confirmed by this list: https://www.localeplanet.com/icu/iso639.html Since you can easily translate pages into languages for which no localization is available, using intl to replacelanguages.jsonfor a list of languages to translate into might not be ideal (it seems the underlying ICU library does have agetISOLanguages()function, but it seems the PHP wrapper extension does not expose that).Still, using intl for e.g. date localization (and probably other things too, like string sorting or comparison) might be interesting to explore.