use of Yy+0/Nn-1/etc... in LC_MESSAGES yesexpr/noexpr

Rafal Luzynski digitalfreak@lingonborough.com
Mon Apr 18 21:22:00 GMT 2016


18.04.2016 19:44 Mike Frysinger <vapier@gentoo.org> wrote:
> On 18 Apr 2016 13:21, Keld Simonsen wrote:
> > [...]
> > Also for bilinggual countries you should allow languages, as in Canada
> > both the English and french values, even for the en_CA locale.
> > The yes/no answers sit in the fingers, so it is a convenience to
> > users to allow theses values, and it is also a cultural convention.
>
> [focusing on this sub-thread since it seems to be most debatable]
>
> the issue is that we don't have a way of determining this automatically.
> what this request boils down is for certain languages to have higher
> visibility in some territories than others. CA currently has 5 langs
> defined for its territory in glibc: en fr ik iu shs. arguably, there
> should be even more as en+fr covers only ~75% of the country (mother
> tongue wise). the others are a fairly long tail.

I guess there are only few such countries so why not to fix the issue
manually?  I assume this is one-time task: you run some script, it
introduces some changes and you have a chance to review what has been
changed and reject some changes before making them public.  I can see
you are making many changes in locale data, I guess you will soon reach
the point where glibc will be up-to-date with CLDR and will not need
many updates.

> so do we try to do a union of all the langs in a territory ? this is a
> bad idea imo as all will simply saturate to the full set -- imo forcing
> a list of "approved" langs on a per-territory basis is kind of backwards
> and there's no reason we wouldn't make this easier (e.g. adding pk_CA,
> zh_CA, es_CA, de_CA, it_CA, etc...).

My suggestion is not to remove what has already been added to glibc locales
and add new language/territory combos (pk_CA, zh_CA and so on) on the users'
demand.

Regards,

Rafal



More information about the Libc-locales mailing list