Good to hear from you!
In answer to your points... if only we lived in an ideal world where we could tear up the standards and start again. Unfortunately, to do so would break oh so many legacy systems and cost industry millions. It simply is not feasible. In addition, every time a new code is allocated engineers and stakeholders have to spend many months discussing solutions as to how they are going to recode all their systems so that it makes sense of the codes that were used prior to the split and can then move forward with the new codes and the legacy codes returning some semblance of true information. This is why we resist requests made on a whim. This is why we have rules and regulations as to when new codes may be allocated. We respect languages, people, countries, governments and industry, indeed all stakeholders, but it is a balancing act which is why we question the need for codes very carefully. In this instance, it would appear that the request is being made purely to add an alpha2 code to the ISO 3166 Administrative Language List and if this is the case then I certainly cannot support such a request as the cost/benefit ratio is totally unbalanced.
Of course, I may be completely wrong and missed the true reason for the request as the level of traffic on this subject is quite high and I must confess I have not read it too deeply.
My considered opinion on the principles affecting "shiKomori" is as follows:
1. If the Government of any independent nation wishes to develop a common national written form of a "language" with divergent spoken forms (as on the different islands of an archipelago), especially for reasons of producing common educational materials for the children of that country, then that initiative should receive sympathetic support from all relevant international bodies or institutions, including all responsible for ISO 639 and ISO 3166
2. Such support should of course be provided after consideration of evidence that such a written language has already been created (including data on whether it has been based primarily or partially on the most widely spoken variety or varieties of the language, e.g. as spoken on the most populated island(s) of an archipelago).
... and on the wider principles involved:
4. Unless I am mistaken, much of the continuing structural weakness or "complexity" of ISO-639 (as a whole) arises from the fusion of two well-defined but essentially incompatible coding-systems : (1) a system of 2-letter tags covering (major) written languages for the purpose of identifying sources of terminology, and (2) a system of 3-letter tags covering (all) spoken and written languages for the purpose of identifying and locating all relevant bibliographic sources on or about each. language.
5. If we have not already abandoned our firm decision of 2012 to review the structure of ISO 639, then may I please suggest that each member of our present JAC forum clarify her or his own opinion on that review, i.e.
- Is such a review unnecessary, impractical, or too expensive ... and why ?
- Is such a review still required ... and with what main objective or objectives ?
Bien cordialement à tous
From: Peter Constable <[log in to unmask]>
To: [log in to unmask]
Sent: Thursday, 10 April 2014, 16:16
Subject: Re: Coherence between codes in ISO 639-1, ISO 639-2 andISO 639-3 ////ISO 639-1 language code request for "Shikomor"
But for something to be coded in 639-1, 639-2 or 639-3, it must be a distinct language. That is a sufficient condition for encoding in 639-3. Therefore, by simple deduction, to be encoded in 639-1 or 639-2, the concept must first be demonstrated that it qualifies for encoding in 639-3.
Your approach, Gerard, appears to be to say that something meets necessary conditions of 639-1, therefore qualifies for encoding in 639-1 (without any additional consideration of sufficient conditions), and subsequently there is an obligation for encoding in 639-2 and 639-3. IMO, that is totally backwards and would lead to significant damage to the standard as well as significant problems for implementers and users.
John, I will add to my earlier comments observations on this information in the request:
>> Evidence: All federal laws of Comoros
>> All local laws in each of the three federated islands Treaties with other countries
>> National Evidence: Government of Comoros
>> Size Evidence: national literature
>> Official Evidence: National language by article 1 of the Constitution
>> Education Evidence: In the three federated islands of Comoros
These are assertions without any ostensive evidence. In this case, based on other information I have seen, I think this evidence is suspect.
Also, there is no indication of any end users or implementers requesting this. All we know is that, having come from the TC46 liaison, it appears that TC46 thinks this is needed. Yet I haven’t heard any of the TC46 representatives hear speak up to explain why it’s needed, nor do I know that this is based on a consensus decision within TC 46 rather than an independent action on the part of certain individuals.
What I know from history is that a _different_ part of TC46 that maintains ISO 3166-1 has a table they maintain and that they like to fill it in with identifiers from 639. Yet this JAC, with representation from TC46, gave clear indication years ago that the table in 3166-1 in question was ill-advised. If the basis of this request is in relation to that table in 3166-1, then TC46 should not expect the JAC to support it.
So, I would find it helpful if our TC46 representatives could clarify the basis of this request coming from TC46, and what the intended usage would be.
In my opinion, there is no doubt that the correct interpretation of the current text of ISO 639 is the "blunt" one:
- every language name coded in ISO 639-1 must also be coded in ISO 639-2, and
- every individual language name coded in ISO 639-2 must also be coded in ISO 639-3.
This is most clearly made explicit in clause "5 Relations entre les parties de l'ISO 639", more specifically in subclause "5.3 Principes", of ISO 639-4 "General principles of coding of the representation of names of languages and related entities, and application guidelines".
Le 10 avr. 2014 à 09:32, Sebastian Drude a écrit :
I did not want to formulate it so bluntly, but I fully agree, although that passage could also be interpreted as “if something is accepted in part (1 and) 2, it is also automatically included in part 3” – but that is clearly not appropriate as part 3 has its own mechanism for inclusion of new code points.
I ask for your understanding if, in the interest of being quick and short, this mail may not fulfil all requirements on form and politeness.
PD Dr. Sebastian Drude, The Language Archive
Max-Planck-Institute for Psycholinguistics
P.O. Box 310, 6500 AH Nijmegen, The Netherlands
Email: [log in to unmask] – Phone: (+31) 24-3521.470