locales: ay_PE: rename Aymara locale

  CLDR/ISO 639 uses "ay" as the language code, not "ayc".
---
 localedata/SUPPORTED                 |  2 +-
 localedata/locales/{ayc_PE => ay_PE} | 36 +++++++++++++++++-------------------
 2 files changed, 18 insertions(+), 20 deletions(-)
 rename localedata/locales/{ayc_PE => ay_PE} (91%)
  

Mike Frysinger <vapier@gentoo.org> writes:

> CLDR/ISO 639 uses "ay" as the language code, not "ayc".

ay is not the same as ayc.

Andreas.
  

On 20 Feb 2016 09:55, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > CLDR/ISO 639 uses "ay" as the language code, not "ayc".
> 
> ay is not the same as ayc.

your feedback is not helpful.  please provide real details instead
of your constant vague one-line responses.

as i mentioned, if you look at ISO 639 [1], it lists the language
"Aymara" as "ay".  there is no other language listed as "Aymara"
or using the code "ayc".  same goes for CLDR.

this locale file in its comments/desc very clearly says it's for
the language "Aymara".

so if you think this patch is wrong, then you need to explain why.
-mike
  

Why should I react to your ad-hominem attack?  Behave yourself.

Andreas.
  

On 20 Feb 2016 11:30, Andreas Schwab wrote:
> Why should I react to your ad-hominem attack?  Behave yourself.

that was not an ad-hominem attack: i attacked your statement, not you.
saying "that idea is bad" is not the same thing as "you are bad".
plus, you still have provided zero information justifying your position.
-mike
  

You are playing a bad game.

Andreas.
  

On 20 Feb 2016 18:44, Andreas Schwab wrote:
> You are playing a bad game.

you're the only one playing a game here: you're refusing to actually
explain yourself or justify your comments.  my take away is this patch
is correct and you're mistaken about ayc-vs-ay.
-mike
  

Is that all you can?  Personally attacking anyone pointing out your error?

http://www-01.sil.org/iso639-3/documentation.asp?id=ayc

Andreas.
  

On 20 Feb 2016 19:44, Andreas Schwab wrote:
> Is that all you can?  Personally attacking anyone pointing out your error?

again, there was no personal attack.  claiming there was one does
not make it so.

you constantly provide short one line e-mails on this list that just
waste people's time as we try to guess what you're referring to.

> http://www-01.sil.org/iso639-3/documentation.asp?id=ayc

that's the 3 letter ISO639-3 code.  ISO639-1 says ay:
https://www.loc.gov/standards/iso639-2/php/English_list.php
Aymara	Aymara	aymara	aym	ay

we use that when constructing the locale name.
-mike
  

Strongest Possible Objection to this change from a technical contact
for the Aymara localization community and the contributor of the
locale (me).

Also maintainer of a Pootle instance with extensive Aymara translations:

http://translate.sugarlabs.org/ayc/

iso-code "ay" represents a language group, whereas "ayc" represent the
variation spoken in Peru.  A more specific designation was chosen for
developing the glibc locale after consultation with multiple
indigenous language organizations (e.g. runasimi.org) in order to
avoid confusion between independent efforts in Peru and Bolivia to
begin localization of mutual unintelligible language variants.

Hoping that this is adequate for you to drop this idea, but I will
muster further arguments and evidence as needed to win the day on this
one.

cjl




On Fri, Feb 19, 2016 at 11:38 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> CLDR/ISO 639 uses "ay" as the language code, not "ayc".
> ---
>  localedata/SUPPORTED                 |  2 +-
>  localedata/locales/{ayc_PE => ay_PE} | 36 +++++++++++++++++-------------------
>  2 files changed, 18 insertions(+), 20 deletions(-)
>  rename localedata/locales/{ayc_PE => ay_PE} (91%)
>
> diff --git a/localedata/SUPPORTED b/localedata/SUPPORTED
> index f8cf0eb..dda8146 100644
> --- a/localedata/SUPPORTED
> +++ b/localedata/SUPPORTED
> @@ -49,7 +49,7 @@ ar_TN.UTF-8/UTF-8 \
>  ar_TN/ISO-8859-6 \
>  ar_YE.UTF-8/UTF-8 \
>  ar_YE/ISO-8859-6 \
> -ayc_PE/UTF-8 \
> +ay_PE/UTF-8 \
>  az_AZ/UTF-8 \
>  as_IN/UTF-8 \
>  ast_ES.UTF-8/UTF-8 \
> diff --git a/localedata/locales/ayc_PE b/localedata/locales/ay_PE
> similarity index 91%
> rename from localedata/locales/ayc_PE
> rename to localedata/locales/ay_PE
> index 9ec91df..f672d33 100644
> --- a/localedata/locales/ayc_PE
> +++ b/localedata/locales/ay_PE
> @@ -3,7 +3,7 @@ escape_char /
>
>  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>  %
> -% Aymara, Southern (ayc) language locale for Peru
> +% Aymara, Southern (ay) language locale for Peru
>  %
>  % Charset: UTF-8
>  %
> @@ -23,7 +23,7 @@ escape_char /
>  % con los códigos ISO-639 disponibles en la actualidad y su disposición a trabajar con
>  % todos los interesados en mejorar la representación de todas las lenguas andinas.
>  %
> -% build with: localedef -f UTF-8 -i ayc_PE ayc_PE
> +% build with: localedef -f UTF-8 -i ay_PE ay_PE
>  %
>  % This file is a part of GNU C Library (glibc) and contains locale data. The
>  % Free Software Foundation does not claim any copyright interest in the
> @@ -35,7 +35,7 @@ escape_char /
>  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>  LC_IDENTIFICATION
> -title      "Aymara (ayc) locale for Peru"
> +title      "Aymara (ay) locale for Peru"
>  source       "runasimipi.org"
>  address      ""
>  contact      ""
> @@ -47,18 +47,18 @@ territory "Peru"
>  revision  "1.1"
>  date      "2011-11-13"
>  %
> -category  "ayc_PE:2011";LC_IDENTIFICATION
> -category  "ayc_PE:2011";LC_CTYPE
> -category  "ayc_PE:2011";LC_COLLATE
> -category  "ayc_PE:2011";LC_TIME
> -category  "ayc_PE:2011";LC_NUMERIC
> -category  "ayc_PE:2011";LC_MONETARY
> -category  "ayc_PE:2011";LC_PAPER
> -category  "ayc_PE:2011";LC_MEASUREMENT
> -category  "ayc_PE:2011";LC_MESSAGES
> -category  "ayc_PE:2011";LC_NAME
> -category  "ayc_PE:2011";LC_ADDRESS
> -category  "ayc_PE:2011";LC_TELEPHONE
> +category  "ay_PE:2011";LC_IDENTIFICATION
> +category  "ay_PE:2011";LC_CTYPE
> +category  "ay_PE:2011";LC_COLLATE
> +category  "ay_PE:2011";LC_TIME
> +category  "ay_PE:2011";LC_NUMERIC
> +category  "ay_PE:2011";LC_MONETARY
> +category  "ay_PE:2011";LC_PAPER
> +category  "ay_PE:2011";LC_MEASUREMENT
> +category  "ay_PE:2011";LC_MESSAGES
> +category  "ay_PE:2011";LC_NAME
> +category  "ay_PE:2011";LC_ADDRESS
> +category  "ay_PE:2011";LC_TELEPHONE
>  END LC_IDENTIFICATION
>
>  LC_CTYPE
> @@ -207,10 +207,8 @@ country_car    "<U0050><U0045>"
>  lang_name    "<U0041><U0079><U006D><U0061><U0072><U0020><U0061><U0072><U0075>"
>  % ay
>  lang_ab    "<U0061><U0079>"
> -% ayc
> -lang_term    "<U0061><U0079><U0063>"
> -% ayc
> -lang_lib    "<U0061><U0079><U0063>"
> +lang_term  ""
> +lang_lib   "<U0061><U0079><U004D>"
>  END LC_ADDRESS
>
>  LC_TELEPHONE
> --
> 2.6.2
>
  

Present in the locale itself is the following comment (in Spanish).

% Los autores desean agradecer a los desafíos de la clasificación de
las lenguas andinas
% con los códigos ISO-639 disponibles en la actualidad y su
disposición a trabajar con
% todos los interesados en mejorar la representación de todas las
lenguas andinas.


Translated:  The authors wish to acknowledge the challenges with the
classification of the Andean Languages with ISO-639 codes currently
available and their willingness to work with all stakeholders to
improve the representation of all Andean languages.


On Sat, Feb 20, 2016 at 3:02 PM, Chris Leonard <cjlhomeaddress@gmail.com> wrote:
> Strongest Possible Objection to this change from a technical contact
> for the Aymara localization community and the contributor of the
> locale (me).
>
> Also maintainer of a Pootle instance with extensive Aymara translations:
>
> http://translate.sugarlabs.org/ayc/
>
> iso-code "ay" represents a language group, whereas "ayc" represent the
> variation spoken in Peru.  A more specific designation was chosen for
> developing the glibc locale after consultation with multiple
> indigenous language organizations (e.g. runasimi.org) in order to
> avoid confusion between independent efforts in Peru and Bolivia to
> begin localization of mutual unintelligible language variants.
>
> Hoping that this is adequate for you to drop this idea, but I will
> muster further arguments and evidence as needed to win the day on this
> one.
>
> cjl
>
>
>
>
> On Fri, Feb 19, 2016 at 11:38 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> CLDR/ISO 639 uses "ay" as the language code, not "ayc".
>> ---
>>  localedata/SUPPORTED                 |  2 +-
>>  localedata/locales/{ayc_PE => ay_PE} | 36 +++++++++++++++++-------------------
>>  2 files changed, 18 insertions(+), 20 deletions(-)
>>  rename localedata/locales/{ayc_PE => ay_PE} (91%)
>>
>> diff --git a/localedata/SUPPORTED b/localedata/SUPPORTED
>> index f8cf0eb..dda8146 100644
>> --- a/localedata/SUPPORTED
>> +++ b/localedata/SUPPORTED
>> @@ -49,7 +49,7 @@ ar_TN.UTF-8/UTF-8 \
>>  ar_TN/ISO-8859-6 \
>>  ar_YE.UTF-8/UTF-8 \
>>  ar_YE/ISO-8859-6 \
>> -ayc_PE/UTF-8 \
>> +ay_PE/UTF-8 \
>>  az_AZ/UTF-8 \
>>  as_IN/UTF-8 \
>>  ast_ES.UTF-8/UTF-8 \
>> diff --git a/localedata/locales/ayc_PE b/localedata/locales/ay_PE
>> similarity index 91%
>> rename from localedata/locales/ayc_PE
>> rename to localedata/locales/ay_PE
>> index 9ec91df..f672d33 100644
>> --- a/localedata/locales/ayc_PE
>> +++ b/localedata/locales/ay_PE
>> @@ -3,7 +3,7 @@ escape_char /
>>
>>  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>  %
>> -% Aymara, Southern (ayc) language locale for Peru
>> +% Aymara, Southern (ay) language locale for Peru
>>  %
>>  % Charset: UTF-8
>>  %
>> @@ -23,7 +23,7 @@ escape_char /
>>  % con los códigos ISO-639 disponibles en la actualidad y su disposición a trabajar con
>>  % todos los interesados en mejorar la representación de todas las lenguas andinas.
>>  %
>> -% build with: localedef -f UTF-8 -i ayc_PE ayc_PE
>> +% build with: localedef -f UTF-8 -i ay_PE ay_PE
>>  %
>>  % This file is a part of GNU C Library (glibc) and contains locale data. The
>>  % Free Software Foundation does not claim any copyright interest in the
>> @@ -35,7 +35,7 @@ escape_char /
>>  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>
>>  LC_IDENTIFICATION
>> -title      "Aymara (ayc) locale for Peru"
>> +title      "Aymara (ay) locale for Peru"
>>  source       "runasimipi.org"
>>  address      ""
>>  contact      ""
>> @@ -47,18 +47,18 @@ territory "Peru"
>>  revision  "1.1"
>>  date      "2011-11-13"
>>  %
>> -category  "ayc_PE:2011";LC_IDENTIFICATION
>> -category  "ayc_PE:2011";LC_CTYPE
>> -category  "ayc_PE:2011";LC_COLLATE
>> -category  "ayc_PE:2011";LC_TIME
>> -category  "ayc_PE:2011";LC_NUMERIC
>> -category  "ayc_PE:2011";LC_MONETARY
>> -category  "ayc_PE:2011";LC_PAPER
>> -category  "ayc_PE:2011";LC_MEASUREMENT
>> -category  "ayc_PE:2011";LC_MESSAGES
>> -category  "ayc_PE:2011";LC_NAME
>> -category  "ayc_PE:2011";LC_ADDRESS
>> -category  "ayc_PE:2011";LC_TELEPHONE
>> +category  "ay_PE:2011";LC_IDENTIFICATION
>> +category  "ay_PE:2011";LC_CTYPE
>> +category  "ay_PE:2011";LC_COLLATE
>> +category  "ay_PE:2011";LC_TIME
>> +category  "ay_PE:2011";LC_NUMERIC
>> +category  "ay_PE:2011";LC_MONETARY
>> +category  "ay_PE:2011";LC_PAPER
>> +category  "ay_PE:2011";LC_MEASUREMENT
>> +category  "ay_PE:2011";LC_MESSAGES
>> +category  "ay_PE:2011";LC_NAME
>> +category  "ay_PE:2011";LC_ADDRESS
>> +category  "ay_PE:2011";LC_TELEPHONE
>>  END LC_IDENTIFICATION
>>
>>  LC_CTYPE
>> @@ -207,10 +207,8 @@ country_car    "<U0050><U0045>"
>>  lang_name    "<U0041><U0079><U006D><U0061><U0072><U0020><U0061><U0072><U0075>"
>>  % ay
>>  lang_ab    "<U0061><U0079>"
>> -% ayc
>> -lang_term    "<U0061><U0079><U0063>"
>> -% ayc
>> -lang_lib    "<U0061><U0079><U0063>"
>> +lang_term  ""
>> +lang_lib   "<U0061><U0079><U004D>"
>>  END LC_ADDRESS
>>
>>  LC_TELEPHONE
>> --
>> 2.6.2
>>
  

Stop your personal attacks.

Andreas.
  

Mike Frysinger wrote:
> your feedback is not helpful.  please provide real details instead
> of your constant vague one-line responses.

This goes too far. Andreas's comments are often quite valuable and bear study, 
and it's typically not that hard to figure them out. Also, Andreas has 
repeatedly shown willingness to expand on his comments when asked nicely, or 
when people clearly misunderstand them. In practice his style is a reasonable 
way to help us out, even if it's terser than the style most people use.

In this case, I expect that Andreas's point is that ISO 639-2 has the following 
entries:

ayc - Southern (Altiplano) Aymara, sometimes called "Aymara" in English
ayr - Central Aymara -- Jaqaru and (now nearly extinct) Kawki
aym - inclusive code for both ayc and ayr

In contrast, ISO 639-1 has just "ay", corresponding to ISO 639-2's "aym". So 
could you explain why is it technically correct to replace "ayc" with "ay"?

Some background: "ayc" has about 2 million speakers; "ayr" has about 700. "aym" 
doesn't have an universally agreed-upon name in English; some call it "Aymaran", 
some "Aymara", some "Jaqi", and some "Aru". There is opportunity for confusion 
here, due to the multiple meanings of the English word "Aymara".

My sources:

Hardman MJ. The Jaqi languages. 2015. http://users.clas.ufl.edu/hardman/

Library of Congress. Codes for the Representation of Names of Languages. 
2014-03-18. https://www.loc.gov/standards/iso639-2/php/code_list.php
  

On 20 Feb 2016 13:56, Paul Eggert wrote:
> Mike Frysinger wrote:
> > your feedback is not helpful.  please provide real details instead
> > of your constant vague one-line responses.
> 
> This goes too far. Andreas's comments are often quite valuable and bear study, 
> and it's typically not that hard to figure them out. Also, Andreas has 
> repeatedly shown willingness to expand on his comments when asked nicely, or 
> when people clearly misunderstand them. In practice his style is a reasonable 
> way to help us out, even if it's terser than the style most people use.

i disagree.  this isn't the first thread where we've wasted time going
back and forth just to get more information out of him because he, for
some reason, doesn't want to write more than one sentence.  the recent
thread "Clarify status of entries in GB 18030-2005" is another good
example of this.  asking people to explain themselves over and over is
wasting all of our time.

had he written what he did in his *fourth* e-mail, this wouldn't have
been an issue, and we could have focused on real issues instead of his
mischaracterizations.
-mike
  

On 20 Feb 2016 21:46, Andreas Schwab wrote:
> Stop your personal attacks.

in order to stop, i would have had to started.  if you actually read
what i wrote, the problem is that your responses are vague.  when i
suggest "let's do X" and you say "no", that isn't useful.  you need
to actually explain your position and provide supporting details.

if you need an example of a useful response, look at Chris's postings:
	https://sourceware.org/ml/libc-alpha/2016-02/msg00618.html

even your best e-mail is barely useful:
	https://sourceware.org/ml/libc-alpha/2016-02/msg00616.html
that single link w/no further explanation isn't great.
-mike
  

Mike Frysinger wrote:
> had he written what he did in his *fourth* e-mail, this wouldn't have
> been an issue

Hmm, well, his fourth email didn't give me any more information than his first 
one did....

At any rate, now that the confusion is cleared up it sounds like we should not 
install the patch as-is. It might not hurt to add commentary to help avoid 
similar confusion in the future.
  

On 20 Feb 2016 13:56, Paul Eggert wrote:
> In this case, I expect that Andreas's point is that ISO 639-2 has the following 
> entries:
> 
> ayc - Southern (Altiplano) Aymara, sometimes called "Aymara" in English
> ayr - Central Aymara -- Jaqaru and (now nearly extinct) Kawki
> aym - inclusive code for both ayc and ayr

ISO 639-2 doesn't have ayc or ayr, it only has aym (which is the same as ay):
	https://www.loc.gov/standards/iso639-2/php/English_list.php
Aymara	Aymara	aymara	aym	ay
	https://www.loc.gov/standards/iso639-2/php/code_list.php
aym	ay	Aymara	aymara	Aymará-Sprache

ISO 639-3 has ayc & ayr, and i guess there it has reclassified aym/ay as a
macrolanguage/parent to ayc & ayr rather than a language by itself:
	http://www-01.sil.org/iso639-3/codes.asp
aym	aym	ay	Aymara	Macrolanguage	Living
ayc			Southern Aymara	Individual	Living
ayr			Central Aymara	Individual	Living

if we're looking at ISO 639-3, it also has a separate jqr:
	http://www-01.sil.org/iso639-3/codes.asp?letter=j
jqr			Jaqaru	Individual	Living

same goes for Ethnologue:
	https://www.ethnologue.com/language/aym
	https://www.ethnologue.com/language/ayc
	https://www.ethnologue.com/language/ayr
	https://www.ethnologue.com/language/jqr

> In contrast, ISO 639-1 has just "ay", corresponding to ISO 639-2's "aym". So 
> could you explain why is it technically correct to replace "ayc" with "ay"?

as i mentioned elsewhere in this thread, i was only looking at ISO 639-2,
and that only has ay.  but what really got me looking was the CLDR:
 - ay - it uses this everywhere
 - aym - it lists it as an alias to ay
 - ayr - listed as deprecated
 - ayc - not mentioned anywhere at all

when we've named locales, we've largely used the ISO 639-1/2 two letter
codes.  since those only have ay, and CLDR doesn't cover ayc at all, i'm
lead to conclude the ayc should really be ay for our needs.

looking at the wikipedia page indicates that Aymara as spoken across Peru
and Bolivia implies they use many of the same words and the distinction
is more along territory than linguistic lines:
	https://en.wikipedia.org/wiki/Aymara_language

having it be ay_PE means we align w/the CLDR and details can be imported
easily.  it also means we can set up ay_BO and be fairly correct -- or at
the very least, it would be more correct than what ay/ayr users have now:
english (or spanish) only.  it's easy to set up aliases for ayc_PE->ay_PE
and ayr_BO->ay_BO so people can have sep translations when needed.

> Some background: "ayc" has about 2 million speakers; "ayr" has about 700.

that's not what the above Ethnologue links say.  they state:
	ayc: 220 k
	ayr: 2 mil
	jqr: 700

> "aym" 
> doesn't have an universally agreed-upon name in English; some call it "Aymaran", 
> some "Aymara", some "Jaqi", and some "Aru". There is opportunity for confusion 
> here, due to the multiple meanings of the English word "Aymara".

the standards bodies seem to use Aymara pretty much everywhere so far.
-mike
  

On 20 Feb 2016 15:02, Chris Leonard wrote:
> Strongest Possible Objection to this change from a technical contact
> for the Aymara localization community and the contributor of the
> locale (me).
> 
> Also maintainer of a Pootle instance with extensive Aymara translations:
> 
> http://translate.sugarlabs.org/ayc/
> 
> iso-code "ay" represents a language group, whereas "ayc" represent the
> variation spoken in Peru.  A more specific designation was chosen for
> developing the glibc locale after consultation with multiple
> indigenous language organizations (e.g. runasimi.org) in order to
> avoid confusion between independent efforts in Peru and Bolivia to
> begin localization of mutual unintelligible language variants.

renaming the locale does not mean the ayc name dies -- we can easily set
up an alias in glibc for it so people can continue to use ayc_PE.  what
matters most i think whether the translated data is mutually intelligible
and have the same basic characteristics.

i.e. look at the content of the ayc_PE file.  if i copy ayc_PE to ayr_PE,
then what in it would be wrong ?  or would the translations/formats still
be (mostly?) correct ?
-mike
  

If you cannot even be bothered to do a 10 second research on the meaning
of ayc I have to question your qualification to work on any locale data
updates.

Andreas.
  

You are demanding other people to do your homework?

Andreas.
  

On 22 Feb 2016 10:18, Andreas Schwab wrote:
> You are demanding other people to do your homework?

cut the crap.  asking people to explain their positions when they
disagree is perfectly reasonable and is actually what i'm demanding.
trying to change the wording doesn't magically change reality.
-mike
  

On 22 Feb 2016 10:14, Andreas Schwab wrote:
> If you cannot even be bothered to do a 10 second research on the meaning

why don't you take 10 seconds to read the posts in this thread that have
details and aren't focused on the distraction of your posting style.

> of ayc I have to question your qualification to work on any locale data
> updates.

i'm more than happy to let other people step up and post updates to the
locale data.  however, no one, including yourself, is doing that.  your
git log in this area has ~10 commits over the last 17 years, and most
are 1 or 2 line changes.

as for qualifications, that is the whole point of peer review.  you can
you can just as easily look at the patches that are posted to the list
as anyone else here.  i've even broken them down into tiny deltas so it
is easy to scan them at a glance rather than doing full rewrites of all
the files.  if you think they're garbage, then feel free to say so *with
supporting details*.

note: i'm not belittling the contributions people have made to locales or
suggesting that some areas of work are more important than others (and
thus one person's contributions are "worth more").  i think we can all
agree that the locale area has been neglected for some time and has been
underserving our users.  2013 had a bunch of good updates by Chris, but
2014 saw 3 changes in total, and 2015 was mostly unicode update by way
of scripted imports.
-mike
  

Mounting personal attacts to people trying to be helpful is arrogant to
its extreme.

Andreas.
  

Your use of personal attacks was the only reason for this useless
thread.

Andreas.
  

Please stop.

Chris Leonard said that 'ayc' is the preferred code for this locale
according to the people who actually use it.  That should be the last
word on the subject: the code should remain 'ayc'.  If CLDR doesn't
agree, it is CLDR that should be changed.

The dispute between Andreas and Mike has been going in circles for
three days and is clearly not going to be resolved by further repeats.
Again, please stop.

zw
  

On 02/22/2016 12:49 AM, Mike Frysinger wrote:
> ISO 639-2 doesn't have ayc or ayr, it only has aym (which is the same as ay):

Ah, sorry, I always get 639-2 and 639-3 confused. Please ignore the 
technical part of my email.
  

On 22 Feb 2016 08:21, Paul Eggert wrote:
> On 02/22/2016 12:49 AM, Mike Frysinger wrote:
> > ISO 639-2 doesn't have ayc or ayr, it only has aym (which is the same as ay):
> 
> Ah, sorry, I always get 639-2 and 639-3 confused. Please ignore the 
> technical part of my email.

yeah, the various iso standards here are so easy to mix up.  i end up
reading each one multiple times, writing down the specific things i'm
trying to find, and then double checking the distilled results to make
sure i didn't mix them up again.  it's one of the reasons i'm trying
hard to have this be automated via python scripts and leverage CLDR:
they've shown that people mix up the fields/values in the data files
constantly too, or just have no idea what the right one is.

when it comes to creating new locales for people, my ideal would be to
have a script that'd generate a skeleton with most filled in for you.
i can't do it for 100% of the file, but i think we can hit like 70%.
-mike
  

I had intended to spare the list a long discourse on the topic of
indigenous language classification and South American politics, but I
know that "Trust Me" usually doesn't fly as an argument on this list.

Some history of note:

The One Laptop per Child project was widely adopted in Peru, placing
many cheap Linux-based computers in the hands of Peruvian children,
many of whom speak indigenous languages in the home but are served by
an education system that primarily uses Spanish as a
language-of-instruction.  Note that these laptops use the Sugar user
int4erface originally developed by OLPC, subsequently spun out and
maintained by the Sugar Labs project of which I have been the
Translation Team Coordinator since 2008.

In 2010 I spent a self-funded week in Lima, Peru to kickoff a
translation sprint with a group of indigenous language advocates held
at local hacker/maker space EscueLab.  Great progress was made and
continues to this day in Aymara and Quechua variants spoken in Peru as
well as newer efforts in other languages of the region like Awajún.
Decisions about glibc development (isocode selection) were made in
consultation with language activist organizations like runasimi.org.

Note that an Aymara speaker would refer to their language as "Aru"
http://translate.sugarlabs.org/ayc/

Quechua (Cusco-Collao)
http://translate.sugarlabs.org/quz/

Awajún
http://translate.sugarlabs.org/agr/

At the time in 2010 there were many discussions about the inadequacy
of the SIL classifications of the Andean languages.  Care was taken in
selecting among the available ISO-codes in order to not block or
confuse future efforts by other indigenous language communities.  The
opinion of many native speakers is that the SIL classifications are
not sufficient to capture the richness of the linguistic diversity of
the Andean languages, there are considerable (and understandable)
sensitivities about being arbitrarily binning together languages that
native speakers would consider distinct.

There have multiple attempts to request modification of the iso-codes
made to SIL, but one must understand that SIL is a somewhat monolithic
organization that is not without a controversial history in South
America that has earned the antipathy of the indigenous languages
community and in fact has been thrown out of countries by the national
government (this is not an invitation to open a discussion about such
decisions, just an acknowledgement that SIL is not entirely
uncontroversial in relevant circles).

https://en.wikipedia.org/wiki/SIL_International#Criticism

There were no existing Aymara or Quechua locales in CLDR at the time
or the developers of those locales would have been consulted as well.
A Spanish language comment was inserted into the glibc locale
welcoming future enqagement on this thorny topic with other language
stakeho0lders.  Now that Aymara and Quechua efforts are beginning in
other areas (e.g. CLDR, Mozilla, etc.) there are people that can be
contacted to further discuss these matters.  Please note that those
efforts are at a very early stage (and unreleased) with only a handful
of strings present in the Mozilla Aymara or Quechua projects (noting
that these are CLDR dependent and not glibc dependent).

https://mozilla.locamotion.org/aym/firefox/

https://mozilla.locamotion.org/quz/firefox/

Whereas, there are thousands of strings actively deployed in a
glibc-dependent project officially supported by the government of Peru
to bring indigenous language educational materials to many children in
some very poor communities.

http://translate.sugarlabs.org/ayc/

http://translate.sugarlabs.org/quz/

 Betamax may have been a superior standard than VHS for videotaping,
but usage wins in the marketplace.

I implore the glibc project to leave the ayc_PE locale as it is for
now (literally for the sake of the children) and I pledge to continue
outreach efforts to the relevant communities (including the relatively
new Mozilla Nativo project) and the CLDR community to seek a more
perfect harmony on representing these languages digitally.  I have
skin in this game in a way that many of you do not, so please "Trust
Me".

cjl



On Mon, Feb 22, 2016 at 3:49 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 20 Feb 2016 13:56, Paul Eggert wrote:
>> In this case, I expect that Andreas's point is that ISO 639-2 has the following
>> entries:
>>
>> ayc - Southern (Altiplano) Aymara, sometimes called "Aymara" in English
>> ayr - Central Aymara -- Jaqaru and (now nearly extinct) Kawki
>> aym - inclusive code for both ayc and ayr
>
> ISO 639-2 doesn't have ayc or ayr, it only has aym (which is the same as ay):
>         https://www.loc.gov/standards/iso639-2/php/English_list.php
> Aymara  Aymara  aymara  aym     ay
>         https://www.loc.gov/standards/iso639-2/php/code_list.php
> aym     ay      Aymara  aymara  Aymará-Sprache
>
> ISO 639-3 has ayc & ayr, and i guess there it has reclassified aym/ay as a
> macrolanguage/parent to ayc & ayr rather than a language by itself:
>         http://www-01.sil.org/iso639-3/codes.asp
> aym     aym     ay      Aymara  Macrolanguage   Living
> ayc                     Southern Aymara Individual      Living
> ayr                     Central Aymara  Individual      Living
>
> if we're looking at ISO 639-3, it also has a separate jqr:
>         http://www-01.sil.org/iso639-3/codes.asp?letter=j
> jqr                     Jaqaru  Individual      Living
>
> same goes for Ethnologue:
>         https://www.ethnologue.com/language/aym
>         https://www.ethnologue.com/language/ayc
>         https://www.ethnologue.com/language/ayr
>         https://www.ethnologue.com/language/jqr
>
>> In contrast, ISO 639-1 has just "ay", corresponding to ISO 639-2's "aym". So
>> could you explain why is it technically correct to replace "ayc" with "ay"?
>
> as i mentioned elsewhere in this thread, i was only looking at ISO 639-2,
> and that only has ay.  but what really got me looking was the CLDR:
>  - ay - it uses this everywhere
>  - aym - it lists it as an alias to ay
>  - ayr - listed as deprecated
>  - ayc - not mentioned anywhere at all
>
> when we've named locales, we've largely used the ISO 639-1/2 two letter
> codes.  since those only have ay, and CLDR doesn't cover ayc at all, i'm
> lead to conclude the ayc should really be ay for our needs.
>
> looking at the wikipedia page indicates that Aymara as spoken across Peru
> and Bolivia implies they use many of the same words and the distinction
> is more along territory than linguistic lines:
>         https://en.wikipedia.org/wiki/Aymara_language
>
> having it be ay_PE means we align w/the CLDR and details can be imported
> easily.  it also means we can set up ay_BO and be fairly correct -- or at
> the very least, it would be more correct than what ay/ayr users have now:
> english (or spanish) only.  it's easy to set up aliases for ayc_PE->ay_PE
> and ayr_BO->ay_BO so people can have sep translations when needed.
>
>> Some background: "ayc" has about 2 million speakers; "ayr" has about 700.
>
> that's not what the above Ethnologue links say.  they state:
>         ayc: 220 k
>         ayr: 2 mil
>         jqr: 700
>
>> "aym"
>> doesn't have an universally agreed-upon name in English; some call it "Aymaran",
>> some "Aymara", some "Jaqi", and some "Aru". There is opportunity for confusion
>> here, due to the multiple meanings of the English word "Aymara".
>
> the standards bodies seem to use Aymara pretty much everywhere so far.
> -mike
  

On Mon, Feb 22, 2016 at 11:39 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> when it comes to creating new locales for people, my ideal would be to
> have a script that'd generate a skeleton with most filled in for you.
> i can't do it for 100% of the file, but i think we can hit like 70%.
> -mike


Mike,

One can achieve a good deal of glibc locale development simplification
with Claude Paroz's excellent Locale Helper website, although I do
like the idea of CLDR's "Survey Tool".

Locale Helper
http://lh.2xlibre.net/

I have used Locale Helper extensively in glibc locale
development/contribution/improvement (about a dozen new/split/major
modification locales so far) and I would encourage others to try it
out.

cjl
  

On Fri, Feb 19, 2016 at 11:38 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> CLDR/ISO 639 uses "ay" as the language code, not "ayc".

Dear Mike (and the rest of the glibc community),

Let me say that I think we all share the same overarching goal,
bringing the goodness of GNU/Linux UIs to as many Aymara speakers as
possible, whatever variation of their mother tongue they speak.

I would like to draw this thread nearer to a close (or at least an
extended pause) with the following counter-proposal.

1) Table the ayc_PE > ay_PE change proposal (for now).  There really
is no urgency driving a change at present.

2) Mike and I can work collaboratively to craft a thoughtful Bugzilla
ticket that captures both his concerns and mine as a placeholder for
continuing investigation and solicitation of views from parties not
currently on the libc-alpha mailing list (e.g. Mozilla/CLDR types,
techy Aymaristas, etc.).

3) Future action will be taken based on the information actively
solicited from relevant stakeholders on a best-path-forward for all.

My rationale for this counter is multi-fold.

a) The locale was orginally committed with the understanding that it
might well be necessary to revisit the isocode issue in future, thus
the Spanish language invitation to further discussion embedded within.
More Aymara speakers are bilingual in Spanish than English.

b) ayc_PE is currently doing yeoman's work for bunch of kids who live
a long llama ride from the nearest Internet cafe.  It would be a
crying shame to disrupt or impede their educational opportunities with
hasty action.

c) It is not clear that Mozilla has thoughtfully considered the issue
of representing multiple Aymara variants as very little work is
evident so far and it looks like Mozilla is using "aym".  However, I
have identified relevant people to contact there.

d) I think you may have said that CLDR uses "ay", but there are no
Aymara locales available from CLDR under any code, either released or
currently pending that I could find.

http://unicode.org/repos/cldr/tags/release-29-beta-1/common/main/

As recently as nine months ago, they closed a request for an Aymara
locale with no more than an RTFM.

http://unicode.org/cldr/trac/ticket/8521

While it is true that the "ay" code appears

in /core/common/supplemental/languageInfo.xml

<languageMatch desired="ay" supported="es" percent="90"
oneway="true"/><!-- fix ICU for es_419 -->

and in /core/common/supplemental/supplementalData.xml

<language type="ay" scripts="Latn" territories="BO"/>

I would note that in the second instance they are listing Bolivia and
not Peru as the territory.

However, it is the appearances in
/core/common/supplemental/supplementalMetadata.xml

<languageAlias type="ayr" replacement="ay"
reason="macrolanguage"/><!-- Aymara, Central ⇒ Aymara -->

<languageAlias type="aym" replacement="ay" reason="overlong"/><!-- [Aymara] -->

that actually give me the most hope that they have ample mechanisms
for dealing with any eventuality that may ultimately occur as the
classification of Aymara variants becomes clearer and more codified.
They do seem to want to roll up to the nearest macrolanguage code, but
that approach may need to give way if more than one variant within a
macrolanguage stakes their claim in cyberspace.

If it weren't for the deadlink to SIL on the following page, this
seems like it might provide a way forward within CLDR.

http://cldr.unicode.org/development/macrolanguages

In any event, I think that CLDR's true position will only be clarified
when someone undertakes the effort to submit an Aymara locale.

e) A Bugzilla ticket represents a central gathering place for what
will most likely be an asynchronous collection of comments.  Far more
suitable than this fast-moving highly technical mailing list where the
discussion would become buried in the rapid flow of other patches
posted daily.  In addition, it is likely that at least parts of that
conversation will need to be in Spanish, including a decent rendering
of the original bug report.

f) Trilingual English-Spanish-Aymara speakers with a working grasp of
the GNU/Linux stack and ISO code standards are rarer than parselmouths
at a quidditch match, so it may take some time to raise awareness and
gather a meaningful consensus.

Is my counter-proposal an acceptable interim solution?

I reiterate my personal commitment to conduct outreach to relevant
members of the Aymara-speaking and technical i18n/L10n communities
beyond this list.  I really don't want this can kicked down the road
forever either.

Warmest Regards,

cjl