This is the mail archive of the
mailing list for the glibc project.
Re: use of Yy+0/Nn-1/etc... in LC_MESSAGES yesexpr/noexpr
- From: Rafal Luzynski <digitalfreak at lingonborough dot com>
- To: Mike Frysinger <vapier at gentoo dot org>, Keld Simonsen <keld at keldix dot com>
- Cc: libc-alpha at sourceware dot org, libc-locales at sourceware dot org
- Date: Mon, 18 Apr 2016 23:21:28 +0200 (CEST)
- Subject: Re: use of Yy+0/Nn-1/etc... in LC_MESSAGES yesexpr/noexpr
- Authentication-results: sourceware.org; auth=none
- References: <20160418024058 dot GI5369 at vapier dot lan> <20160418112150 dot GB10597 at rap dot rap dot dk> <20160418174438 dot GT5369 at vapier dot lan>
- Reply-to: Rafal Luzynski <digitalfreak at lingonborough dot com>
18.04.2016 19:44 Mike Frysinger <firstname.lastname@example.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
> 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'