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

[Mike Frysinger <vapier at gentoo dot org>]

On 18 Apr 2016 23:21, Rafal Luzynski wrote:
> 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.

CLDR is not a fixed entity, nor does the data/languages it represent stay
fixed.  customs/baselines change which means the data changes.  we cannot
assume that because we set some value to X at ver V it shall forever stay
that way.  hence i'd like to get this automated in some way.

> > 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.

users make requests all the time, and we *always* must evaluate whether
they are correct appropriate.  it's not that we're worried about malice
from users, but sometimes they are simply mistaken, or they're making a
request that is not what we would consider the majority/normal.  this is
why i'm pushing for any deviation (which this is) to have some method to
the madness.  by just using the CLDR, we have a simple position: if you
think your change request is correct, then follow/convince CLDR.  their
processes/direction seems to line up with what we want as well.
-mike

Attachment: signature.asc
Description: Digital signature