This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mix/match lang/territory


* 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]