Improvements in internationalization and localization
The musl C library has significantly enhanced its internationalization capabilities, addressing issues with locale handling and number formatting. The changes, funded by an NGI Zero Core grant, are currently in testing and will be integrated into the Nura operating system after the v26.12 release.
The musl C library, a foundational component of the Nura operating system, has received a substantial update to its internationalization and localization framework. This project, supported by an NGI Zero Core grant, introduces several new features and a significant breaking change that will affect how the system handles different languages and number formats.
From a user's perspective, the most visible improvements are in how the system handles language-specific data. musl now correctly distinguishes between abbreviated and full names for months, such as 'May' versus 'Mai', a distinction that was previously lost. The library also gains support for using a comma as a decimal separator, which is the standard in many European languages for writing numbers like 'one and a half' as '1,5'.
Another key change is the implementation of standard ordering rules for files and other data. Previously, the ordering of characters was inconsistent, with 'A' and 'a' sometimes appearing in different places. The new implementation ensures that 'A' and 'a' are grouped together and placed before 'B' and 'b'. While support for umlauts like 'ä' is now in place, the tooling required to generate the necessary locale files is not yet fully ready.
Breaking changes for unsupported locales
The update introduces a breaking change that could impact users of languages not yet supported by musl. After the changes are integrated, systems with a locale that musl does not recognize will stop seeing translations in their language, even if the applications themselves have those translations available. This is a deliberate shift to ensure consistency within the system.
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.
This previous behavior, while convenient, led to a disjointed user experience where the UI might be in one language while dates or numbers were in another. It also removed the incentive for developers to create proper locale definitions for musl. The new approach is stricter but more reliable, and the changes will not be part of a stable release until v27.06, providing ample time for the community to adapt.
To mitigate the impact of this change, the project is seeking community help. The primary task is to add missing locale definitions for languages that are not yet supported by musl. This is a straightforward process that involves copying a template file and adding the necessary definitions. The project also welcomes more complex solutions, such as an automated system using the Unicode Common Locale Data Repository (CLDR).
Related
