This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: mix/match lang/territory
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: libc-alpha at sourceware dot org
- Cc: pander at users dot sourceforge dot net
- Date: Sat, 23 Apr 2016 14:01:29 +0200
- Subject: Re: mix/match lang/territory
- Authentication-results: sourceware.org; auth=none
- References: <1461298610-19221-1-git-send-email-vapier at gentoo dot org> <87a8klk4jp dot fsf at mid dot deneb dot enyo dot de> <20160422190728 dot GC5369 at vapier dot lan>
* Mike Frysinger:
> which leaves us with the ones that are actually defined in this locale:
> LC_TIME
> - day/month fields are def language specific.
> - all the other fields are largely territory specific (the way date &
> time are displayed locally).
But you use ISO 8601, not the local conventions. I'm not saying this
is wrong, my hunch is that most en_NL users could live with that (it
would definitely work for me with a hypothetical en_DE locale).
We already have a request for ISO 8601 variants of locales. It is not
clear if this affects date_fmt or just d_fmt (we probably have
requests for both). I think adding these variants would make more
sense, and then users can pick that locale along with nl_NL.
> LC_ADDRESS
> - country_name & lang_* are def language specific.
> - all the other fields are territory specific.
geocode/geoclue uses _NL_ADDRESS_POSTAL_FMT to determine the ordering
of street name and street number. evolution-data-server uses
_NL_ADDRESS_COUNTRY_AB2. I can't find any other users.
So in practice, it should be fine to use nl_NL here. Unless there are
other ways to access this information besides _NL_ADDRESS_.* and
nl_langinfo_l.*(POSTAL|COUNTRY|LANG).
(Without any users, we can't justify a decision which language to use
for the translatable fields. Users may prefer either variant.)
> LC_IDENTIFICATION
> - clearly includes both lang & territory details, but not nearly as
> important as the categories above. could just be lived with.
_NL_IDENTIFICATION_TERRITORY is used by LightDM, but it assumes that
it is in English (which matches what glibc currently does for nl_NL,
fr_FR and de_DE at least).
> this one can be a bit murky, so i guess
> LC_MONETARY
> - currency fields are def territory related.
> - the others are semi-lang dependent/personal preference (digit spacing
> and such), but there's no way to customize on a sub-category basis.
Hmm. I think the main obstacle here is that we want the numbering
format to match LC_NUMERIC, and you assume that users want en_GB
there. This is probably the right choice.
So the question is: What programs actually rely on LC_MONETARY?
If there is a body of software which uses LC_MONETARY, we need a
compelling solution for this aspect of the problem. As far as I can
see, it is the only one which is really not addressable with LC_*
settings.
> so the question before us is how do we want to proceed ? telling users
> "that sucks but that's just how it goes" doesn't seems like the right path
> to me long term. exploding combinations of lang/territories also sucks,
> but it's the only way today to accomplish this.
Agreed.
> maybe we could spec out a new format for the env vars that'd allow people
> to mix & match lang & territory themselves ? POSIX leaves the format of
> locale names up to the implementation after all, as well as the output of
> the localedef tool. we could do something like:
> LANG=[lang]:[territory]
> LANG=en_US:nl_NL
> and we'd take care of filling in lang fields using en_US and territory
> fields using nl_NL. this would go beyond just category selection since
> as i described above.
Do we need anything besides an override for the currency symbols in
LC_MONETARY?