Message ID | 1455943135-26037-1-git-send-email-vapier@gentoo.org (mailing list archive) |
---|---|
State | Rejected |
Delegated to: | Mike Frysinger |
Headers |
Received: (qmail 128922 invoked by alias); 20 Feb 2016 04:39:02 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 128890 invoked by uid 89); 20 Feb 2016 04:39:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: Yes, score=6.8 required=5.0 tests=BAYES_50, FOREIGN_BODY1, RP_MATCHES_RCVD, SPF_PASS autolearn=no version=3.3.2 spammy=todas, disponibles, disposicin, lc_time X-HELO: smtp.gentoo.org From: Mike Frysinger <vapier@gentoo.org> To: libc-alpha@sourceware.org Cc: cjlhomeaddress@gmail.com Subject: [PATCH] locales: ay_PE: rename Aymara locale Date: Fri, 19 Feb 2016 23:38:55 -0500 Message-Id: <1455943135-26037-1-git-send-email-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit |
Commit Message
Mike Frysinger
Feb. 20, 2016, 4:38 a.m. UTC
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%)
Comments
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
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