[Data] Redesign Locale and Rounding Data Structures #15
Labels
enhancement
New feature or request
Milestone
Comments
GrammAcc
added a commit
that referenced
this issue
Feb 27, 2024
I changed the `system_locale` function to check if the locale is the default POSIX C locale and interpret it as `en_US` if that is the case. The C locale is close to en_US, so this is a reasonable mapping to a valid linearmoney internal locale. This behavior may change while working on #15, but for now, this should be a sufficient workaround for this bug. Most workstations won't be using the C locale, but it's the default on POSIX systems, so machines like an Ubuntu server could have this locale if they weren't configured for a specific locale before partitioning. I also added a test case for the C locale and modified the other test cases for the `system_locale` function based on the new behavior. I also had to modify the GH Actions workflow file to make sure all environments have the requisite locales. Fixes #14
This was referenced Feb 27, 2024
GrammAcc
added a commit
that referenced
this issue
Feb 27, 2024
I changed the `system_locale` function to check if the locale is the default POSIX C locale and interpret it as `en_US` if that is the case. The C locale is close to en_US, so this is a reasonable mapping to a valid linearmoney internal locale. This behavior may change while working on #15, but for now, this should be a sufficient workaround for this bug. Most workstations won't be using the C locale, but it's the default on POSIX systems, so machines like an Ubuntu server could have this locale if they weren't configured for a specific locale before partitioning. I also added a test case for the C locale and modified the other test cases for the `system_locale` function based on the new behavior. I also had to modify the GH Actions workflow file to make sure all environments have the requisite locales. Fixes #14
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The structures used to load and parse locale and rounding data is not ideal. I designed these systems iteratively and in a hurry while I was trying to implement other features.
The current data structures work, and because the locale and currency systems are self-contained within the linearmoney library, the way that data is represented doesn't really cause any problems as far as interoperability is concerned, but I have run into an issue with the
system_localefunction not working on Windows due to different locale string conventions. Also, thesystem_localefunction doesn't work with the fallback C locale due to an oversight when I first implemented it. See #14.The goal of this redesign will be to determine how closely the linearmoney locale system wants to comply with the posix standard. Posix compliance is good, but the keys used by Posix locales are very confusing to use, and a more human-readable set of properties would be helpful for users who want to use custom locales and override specific characteristics of a locale without creating an unreadable mess.
The tradeoff with having a more human-readable data structure is that we end up with yet another format for the same thing. I personally am heavily in favor of compliance with the current standards, so I will most likely ensure full posix compliance, but I will still take some time to weigh the pros and cons thoroughly.
The current data structure is pretty close to fully compliant with the posix locale standards, but a few of the keys used in a locale dictionary are represented differently to make parsing easier in the current implementation of the l10n functions. Basically, the current implementation is the worst of both worlds. It's not completely posix compliant and it's also not very readable. This is what I want to fix.
#11 needs to be completed before this issue in order to ensure we don't introduce any regressions while changing the CLDR processing script to accommodate changes in these data structures.
The text was updated successfully, but these errors were encountered: