As part of an NGI Zero Core grant, musl has now massively improved its support location and internationalization. Although the changes are not yet fully merged in musl and Alpine, they are ready for testing, and you can expect them to land in Nura at some point after the v26.12 release.
New features
From the user perspective, a few new features have landed with these changes:
- On languages where May is longer than 3 letters, musl is now able to distinguish between abbreviated and non-abbreviated versions.
- There is now support in musl for the decimal separator to be a comma. Languages where "one and a half" is written as 1,5 instead of 1.5 will now get numbers in the right format, provided localization files for the language exist.
- Ordering of files (and anything else that depends on the C library for ordering) now follows standard ordering rules. For example, "A" and "a" are now ordered together, and always come before "B" and "b", which wasn't the case before. Ordering of some specific characters might not be perfect yet. For example, different languages have different expectations of where should umlauts like "ä" be placed in relation to "a". musl now has support for that, but the tooling that takes the rules and transforms them into files that musl can read don't support this yet.
Breaking changes
From the user perspective, these changes come with a breaking change. After the changes get integrated, languages which don't have a musl-locale will stop seeing translations to their languages in the UI, even if the apps have translations for them (if you want to help, please see the section below). Since the updated musl behavior will not land in a stable release before v27.06, there is plenty of time for the community to collectively reduce the impact of this change.
This change had to be made, because previously musl would just always accept any kind of locale being set. If it could find the locale, it would set the language appropriately. If it couldn't, it would set the language internally to English (the C locale to be more specific), but assure the consumer that the system was in the locale requested. While this allowed things like apps to use the translations they had available, even if musl lacked those translations, it created inconsistent behavior. The UI would be shown in one language, while the dates for example would be in the wrong format. It also removed incentives to do the right thing and work on locales for musl, and broke testing and some other specific use-cases, as the answer to "does my system support this locale?" would always be "yes", even if asked to set the language to Elvish 🧝♀️.
If you want to get more technical details and the rationale behind all the changes, you can search for the relevant threads in the musl mailing list, most specifically the latest patchseries.
Thanks a lot to Rich, Achill, and Pablo for their work on this project, and to NLnet and NGI Zero Core for funding this work.
Help wanted
To avoid losing app translations in your language due to this breaking change, we need to add translations to musl for the said language. This is relatively easy, simply copying a file and adding the definition in your language. Having the definition in your language will be greatly appreciated!
Alternatively, an automated solution using the Unicode Common Locale Data Repository (CLDR) is potentially also possible, but is a harder problem to solve. Any hero wanting to give it a try would be seriously welcomed. Please have a look at musl-locales#1 if you want to help with that.
If you appreciate the work we're doing with Nura and want to support us, consider contributing financially via OpenCollective.