Sorry for my confusion on Livonian.
Ambiguity may not be costly, though in some cases it can be.
Consider the situation with zh: There is a large body of usage in which zh is used to mean Mandarin, but there are also clear cases in which zh is used in relation to other Chinese languages. For that reason, we deemed zh to be a macrolanguage encompassing IDs for Mandarin Ė cmn Ė and other specific Chinese languages. So, now implementations have IDs that can be used to distinguish (say) Mandarin (cmn) vs. Cantonese (yue). However, there will also be problems in managing the relationship between these specific IDs and all the existing usage of zh. It is that additional problem that can be costly.
So, if Latgalian is only ever of marginal interest except in certain limited application scenarios, then most applications may be able to continue using lav for Standard Latvian resources and never have to worry about how to relate lav with IDs for the more specific varieties, in which case the ambiguity introduced with the macrolanguage option will not be significant. If that ever changes, though, the macrolanguage option will entail costs for implementations in some larger degree.
Thanks for comments, Peter.
In the meantime, I have been corresponding with the requester. He asked, basically, what are the issues? This was my summary of them for him (just for the record here, not for new knowledge to this group):
If the macrolanguage approach is chosen, and approved, there is one issue:
The existing [lav] code element will remain, and will continue to include both Latvian proper and Latgalian within its scope of meaning, as a macrolanguage. Because of this, the new code element created to denote Latvian more strictly ("Standard Latvian" might be too strict, or might be appropriate.) will likely get used very little. The drawback is that there will be two code elements that overlap to a very high degree, and the [lav] code will still be used in most cases, even if the more specific new code for Standard Latvian is actually more appropriate. The majority of users coding anything (within software, on a webpage, in a library catalog, etc.) will continue to use the more widely known code, except where they really do want to identify Latgalian specifically.
If the other approach, just creating a new code element for Latgalian, is chosen, there are two issues:
1. There will be an unknown proportion of uses of [lav] where the code really should be for Latgalian, but there will be no overt mechanism to encourage system managers to look for and update those instances. This is an issue in general systems with lots of retrospective data, like large library catalogs. We expect the proportion to be relatively small (the Library of Congress did a quick assessment and estimated it to affect less than 0.5% of [lav] coded works). Another mitigating factor is that creators of both resources and systems (including websites) specifically targeting Latgalian materials will be early, intentional adopters of the new code element, making the change from the 'inadequate' [lav] code element to the new one.
2. The larger sociolinguistic and historical connection between the two language varieties would not be reflected in the standard. This means that for contexts where Latvian and Latgalian really ought to be considered "one language", there will be no proper means of expressing that. This may be most relevant for historical materials.
I sent this message last week, and he has not yet replied. We have basically the same issue with Estonian now, as well. In a world where many applications of a given code element will never be reviewed and updated, we will always have to deal with these matters. I don't see this changing until all the parts work together on a wholly different basis (and maybe not then, either). The cost of updating is much higher and more direct to managers of materials than is the cost of ambiguity, which is distributed, and borne more by users of resources. The cost of not changing at all is borne by those not served by the current system, largely creators and users.
The macrolanguage solution also has the merit of tying the creation of the Latgalian code element to the [lav] code at a referenceable point in time, even if the proposed change is not fully adopted (i.e. the macrolanguage aspect is rejected), as was the case with Khasi and Lyngngam (http://www.sil.org/iso639-3/chg_detail.asp?id=2007-064 ). In that case, at least there is a formal record of Lyngngam being associated with Khasi prior to the creation of the new code element.
Livonian need not be at issue here at all. It is considered to be within Finno-Ugrian languages [fiu] in Part 2. Being Uralic/Baltic-Finnic, it is classed closer to Estonian than to Latvian, which is Indo-European/Baltic, though Latvian has had significant influence on it. (Michael just said some of this, too.)
2009-06-29 12:55 PM
Sorry for not replying sooner.
An important consideration: if the scope of lav is changed to macrolanguage and an entity is created and mapped as being encompassed by lav, then what of Livonian and (more importantly) Standard Latvian? Would liv be encompassed by lav, and would we create an new entity for Standard Latvian? It seems that at least the latter would be necessary. But then that would create issues for Latvian resources: there would be confusion about whether lav or the new ID should be used. (This is the same issue that has existed with zh and cmn for Chinese / Mandarin, and itís a pain.)
The down side to the first option would be that some of the existing uses of lav are for Latgalian. I donít know how likely that would be. We do know, though, that thereís a fair amount of usage of lav for Standard Latvian, and thatís what would be impacted by the second option.
So, I lean toward the first option, though thatís assuming that there is very little or no usage of lav for Latgalian.
From: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] On Behalf Of Joan Spanne
Sent: Friday, June 05, 2009 8:06 AM
To: [log in to unmask]
Subject: Fw: Inclusion of Latgalian language in ISO639
Lucas gave helpful information wrt the very small percentage of [lav] that appears to be more specifically Latgalian in the Library of Congress (and even smaller proportion known to be Samogitian--though that actually relates to Lithuanian, not Latvian). That would indicate that separating Latgalian from Latvian without a split or a change to [lav] to the scope of macrolanguage would be acceptable.
However, I would like to forward this note from one of the two distinct requesters, and ask the thoughts of the JAC specifically on the question of which is approach is preferred by the JAC:
1. simply allowing the creation of a separate code element for Latgalian in Part 3, with no change to [lav]
2. change [lav] to a macrolanguage, with the constituents of Standard Latvian and Latgalian.
The requester has noted the decision made in the 2009 series of changes for ISO 639-3 with regard to Estonian, and sees it as a good pattern to follow. He also supplies some additional information on development movements.
Thanks in advance for considering and responding.
----- Forwarded by Joan Spanne/IntlAdmin/WCT on 2009-06-05 09:23 AM -----
Jancs <[log in to unmask]>
2009-05-29 04:06 AM
Quoting [log in to unmask]:
> Hello Janis,
> Another individual has initiated a request to add Latgalian to the ISO
> 639-3 standard. Thank you for the additional information you supply. I
> anticipate I will be able to post more information on that request to the
> ISO 639-3 website within the next few weeks. It is a complex situation
> because of the relationship to Latvian.
I'd like to add some more information on the subject:
a week ago I submitted an initiative document regarding this problem
to the States Language commission (SLC) of Latvia. Knowing from whom
came the first initiative could be helpful to unite the efforts and
get academic support for the issue. As far as i know, this initiative
does not comes from the memebers of SLC as the person (professor
A.Stafecka) in lead of Latgalian grammar subcommission was absolutely
unaware about it and actually encouraged me to write respective letter
Yes, I agree that the process could be not easy. As I see it at the
moment is that the Latvian should be changed to macro language (as out
neighbours - Estonian) and added Latgalian as the sub-language (also -
like in the case with Estonian and Voro). That example showed that the
intitiative group of Voro changed the est status and succeeded in
introduction of Voro.
> Jancs <[log in to unmask]>
> 2009-05-20 02:51 AM
> [log in to unmask]
> Inclusion of Latgalian language in ISO639
> Dear sirs,
> I am working at the development of the spellckecking tools for Latvian
> language and, as I feel the main part of the work is comming to an
> end, I wanted to do the same for my mother tongue - Latgalian (I am
> Latgalian speaking and writing).
> My work can be seen at http://dict.dv.lv, where both projects -
> Latvian and Latgalian - are listed.
> Unfortunately, it is not possible to use Latgalian as the document
> language, because it is not listed in respective international
> standards (ISO639-3 particularly), only mentioned in ISO639-2 as the
> member of Baltic language group, which does not help to solve the
> issue with spellchecker's identification.
> Can you tell me what procedure must be followed to initiate an
> inclusion of Latgalian language in the standard??
> To give some more information on language for more info please see:
> Sincerely yours -
> Janis Eisaks
> This message was sent using IMP, the Internet Messaging Program.
> X-Quarantine ID /var/spool/MD-Quarantine/03/qdir-2009-05-20-03.59.47-001
VÁÔ 243 mieneūi da pensejis
This message was sent using IMP, the Internet Messaging Program.
X-Quarantine ID /var/spool/MD-Quarantine/05/qdir-2009-05-29-05.07.05-001