-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Starting with localization #3997
Comments
There is also |
I'm no longer sure |
I was running into essentially the same problem for my own command line tools.
|
Not yet. We should start talking to some people about that :)
Translations are out of scope for a while for us I think, but if you want it, I think Project Fluent is the gold standard there.
If there is a significant amount of code, it should definitely go in a separate crate.
Yeah I think we should support mixed locales. At least, if by mixed locale you mean that for example collation is done in one locale and number formatting in another or something like that. |
Exactly. I use LC_MESSAGES in English (for searchability and because translations tend to be poor), but I use sv_SE.UTF-8 for everything else, except for collate where I prefer C.UTF-8 for case sensitive sort. |
TL;DR: I want to add a new util for locale generation and provide locale-aware functionality in
uucore
uutils is currently following the
C
locale for most of its operations and the locale settings of the system are mostly ignored. This has led to issues and PRs like these:expr
is failing with multibyte chars #3132We've mostly been putting this off due to missing libraries in Rust, but recently, this has changed with the release of
icu4x
. It covers many of the things we need like locale-aware datetime formatting, locale-aware collation, etc..However, it requires data to operate on, which is different from the usual data generated by
locale-gen
and friends (if I understand correctly). There are essentially 2 viable ways to include data withicu4x
1:BlobDataProvider
).BakedDataProvider
).Since we don't know up front what locales we might need, I think we need to use the
BlobDataProvider
and allow the user to generate their own locale data on command. So, I propose we do the following:locale-gen
or something similaricu_datagen
crate2.uudoc
back when it automatically downloaded examples, so it needs to be optional.3uucore
as much as possible, so that the utils themselves don't have to bother with checking the right environment variables, loading the icu data, etc..LC_COLLATE
,LC_ALL
andLANG
env vars need to be checked.sort/collate
function that checks (and caches) the locale and performs the correct collation.uucore
.Do you see any problems with this approach? Are there alternatives we should explore first?
Footnotes
They also have
FsDataProvider
which is meant for development only. ↩This crate also has a CLI, but we need to tailor it for use with coreutils, by setting nicer defaults for our purpose. ↩
icu_datagen
usesreqwest
, which will lead to similar problems as in https://github.com/uutils/coreutils/pull/3184 ↩The text was updated successfully, but these errors were encountered: