Re: [PATCH] locales: ay_PE: rename Aymara locale

[Chris Leonard <cjlhomeaddress at gmail dot com>]

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