Hoi,
When this case cannot be made convincingly, we have a situation. When a
macro language code is proposed it is no longer abstract and as a rule it
is a bad thing to allow for macro languages. When it is needed I want the
argument to be really convincing.
Thanks,
GerardM
On 5 July 2017 at 15:47, Steven White <Koala19890(a)hotmail.com> wrote:
Gerard, I think avoiding macrolanguage projects
"as much as possible" may
be overstating the situation a bit. After all, frequently it's a pretty
close thing whether the current coding—macrolanguage plus daughter
languages—or treating the whole thing as language plus daughter dialects—is
more accurate. Obviously, we are not going to second-guess the whole ISO
639 infrastructure. But if the daughter languages of a macrolanguage
community are highly mutually intelligible, and if the respective language
communities would prefer to see everything grouped into a single langcode,
I don't see why we wouldn't want to accommodate that.
Similarly, if most branches of a macrolanguage are dead, and the community
of the remaining branch is willing to accept the dead branches within the
project, I don't see why we wouldn't want to accommodate that, especially
if the macrolanguage identification is far more obvious to the world than
the daughter-language identification. (I think here of Yiddish. Obviously,
that example is technically moot, since Yiddish projects have existed long
before the current policy. But most Yiddish today is *de facto* Eastern
Yiddish. There is no point in calling those projects "Eastern Yiddish"
instead of "Yiddish"; that would just be confusing to most people, and to
the extent anyone would create content in Western Yiddish, I'm sure there
would be no problem in placing that content in the "Yiddish" projects.)
Steven White (StevenJ81)
Sent from Outlook <http://aka.ms/weboutlook>
_______________________________________________
Langcom mailing list
Langcom(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/langcom