I think there is a misunderstanding with regards to the scope of the
request. Both Kurmanji and Sorani Wikipedias actually currently are labelled
in interwiki links and bills itself sometimes as "Kurdish Wikipedia". These
are both local issues and this request is not asking them to stop that. The
only thing this request is for, is to change the language code of ku.wp. It
is improper to use a macrolanguage code for a Wikipedia that is not written
in a "unifying variety" (= fa.wp is written in official Farsi, ar.wp is
written in Modern Standard Arabic, zh.wp is written in standard written
Chinese, but there is no "Standard Kurdish" and ku.wp is just written in a
regular Kurdish variety which should be treated as equal to all other
Kurdish varieties). I am not talking about how the Wikipedia presents
itself, I am talking about how we present it, by housing it at the URI
http://ku.wikipedia.org/
In this case, I do not think anything local changed by langcom, the
foundation, or anybody else unless it creates legal problems. The only thing
this request covers is the code itself, which is currently wrong since "ku"
is a macrolanguage code but ku.wp is not truly a macrolanguage wiki.
2011/9/16 Milos Rancic <millosh(a)gmail.com>
2011/9/16 M. Williamson <node.ue(a)gmail.com>om>:
It's not irrelevant because if approved, it
could be added to list of
pending name changes.
The problem with the request is that it's not in the scope of Language
committee. Renaming "zh-min-nan" into "nan" is in the scope, as it
deals with simple code change. Renaming "als" into "<whatever>"
is
also inside of the LangCom scope, as "als" is not proper code. At the
other side, stability requires that "fa" stays as "fa", as
"fa" is
implicitly Farsi (besides being "macrolanguage" Persian).
However, requiring that one project doesn't include texts written in
other language and/or requiring that one project doesn't promote
itself as the home project for other languages which have their
Wikimedia projects -- that's the task for community and/or WMF; likely
for GRC. If we want to solve the problem properly. LangCom should be
consulted in this case, but it's not LangCom's which should deal with
dispute resolution among couple of communities.
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/foundation-l