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 <[email protected]> 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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/langcom
>
>
_______________________________________________
Langcom mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/langcom