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

_______________________________________________
Langcom mailing list
Langcom@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/langcom