 |
 |
Dear Rebecca There are several problems with your suggestions for Bokmaal and Nynorsk. In message <[log in to unmask]> you wrote via [log in to unmask]: > To ISO 639/JAC: > > We had a meeting here at the Library of Congress of catalogers who are > applying the language codes, and the difficulty of applying the three > Norwegian codes was made clear. It was felt that at least in the U.S. > and probably most places outside of Norway those applying the codes may > not have the expertise to be able to determine and it may not be > desirable for searching and retrieval purposes to make such fine > distinctions. There is also the problem that there exists two forms of the > language, one based on Danish and one on Old Norse (this taken from > Havard's ISO/DIS 639-l Annex C), while there are now 3 codes. As Havard > stated at our meeting, this is a national rather than international need, > although all of these codes are needed in Norway. This could indicate one of two possibilities: (a) that ISO 639-2 needs to be changed, or (b) that LC cataloguers need to have available more information to distinguish these languages, such as was suggested by Keld Simonsen. Thus far, only (a) seems to have been considered as a possibility. There are also needs outside of Norway, e.g. in some other Scandinavian countries, as well as others - see also below. > This is a case that is bound to come up time and time again in this > standard, when local needs conflict with international needs. There are also parts of the the USA (e.g. Minnesota) where there are significant populations with a Norwegian heritage, where these distinctions about different languages will be important. > Those of us maintaining large bibliographic databases and producing > large numbers of records may not be able to or want to make the fine > distinctions that might be made in the countries where the language > is spoken. Cataloguing agencies who are producing large numbers of records usually - it is to be hoped - recruit cataloguers who can pick up nuances about specific languages, even if they are not regular speakers of those languages. In practice, there are also statistically likely guesses that they can make based on place of publication, or the occurence of certain key words (cf. Keld Simonsen's list of examples) which can confirm that it is a specific language or another one that should be coded. > Therefore I would like to propose the following solution. The new codes > that were approved (nno and nob) would be appended onto the more general > code for Norwegian. Thus, a hierarchical type of coding would be used: > nor-nno Norwegian Nynorsk > nor-nob Norwegian Bokmaal For specific languages a hierarchical distinction for languages would be a new departure: this was not suggested in Washington, for example, for Bosnian or Croatian. Such a major change of principle would need major agreement across the JAC, and confirmation by ISO/TC37/SC2 and ISO/TC46/SC4 in my view. Additional codes using dashes have not been hierarchical in that sense, but linking two different concepts, e.g. language and country. In the case of sign languages, "sgn-nob", "sgn-nno" - and in theory I suppose "sgn-nor" - would all be distinct possibilities. I have not checked the JAC sign langauge document to check which possibilities exist now. The codes nor-nno for "Norwegian Nynorsk" and nor-nob for "Norwegian Bokmaal" would be at odds with these possibilities, and also extremely confusing. In any case, this option will not be available in the MARC 008 field, where a fixed field is applied: only "nor", "nob" or "nno" are available. It will be necessary for the cataloguing agency to develop guidelines. One simple one could be "the Library of Congress has used "nor" for Bokmaal and Nynorsk in the past: at present it will continue to do so, and not use the distinctive "nob" and "nno" codes." If you did so, you would of course have to consider whether you wanted to convert any "nob" and "nno" codes" to "nor" for internal use. > For the alpha-2 list we would do the same, although I would argue that > only the alpha-3 code would be needed as an extension: > no-nno Norwegian Nynorsk > no-nob Norwegian Bokmaal > An alternative could be using the alpha-2 code as the second part: > no-nn > no-nb The fact that either of these possibilities look possible, leading to further ambivalent coding, is another argument against using hyphen-linked codes for Bokmaal and Nynorsk. > We could consider applying this mechanism in the future where needed for > these types of situations, but we would NOT go back and look at the codes > we have as to whether others are similar. Only with a major change of principle agreed by the ISO 639 JAC, with confirmation by ISO/TC37/SC2 and ISO/TC46/SC4. > This solution would be consistent with the ISO 3166 subentity codes, where > the code for a subentity is attached to a country code to be more > specific. Bokmaal and Nynorsk are not "subentities" they are specific languages. In any case neither ISO 639 or ISO 639-2 go into great detail about how ISO 3166 codes are applied: they merely give a few examples. > It would also be consistent with the direction in the current > proposed revision to RFC1766, where it is stated that a subtag may be used > in conjunction with a language code (example is: no-nynorsk, no-bokmaal). > The only difference is that a code would be used for the subtag, rather > than a language name. That example is because the current version of RFC 1766 is based only on the 1998 edition of ISO 639. The proposed revision which Michael Everson mentioned at the meeting would result in the use of specific codes - not hyphen-lined codes - for Bokmaal and Nynorsk. > I would like to open up discussion on this proposal during the next > several days. Please consider it and comment between now and next Tuesday, > 7 March. Then I will send out a voting form and we will vote on it. If you plan to do that, there need to be new ISO 639 JAC procedures put in place to cover the validity of earlier votes, and how long a vote may last before it is overturned. Currently we do not have such procedures. > Although we have previously voted on these codes, I don't see this > possible change as a complete reversal of that decision, but a > reformulating of how the codes are presented. I can't agree on that last point. It still uses the new codes, but proposes how codes should be used, which is outside the scope of ISO 639. Nor does this proposal get over use in fixed 3-letter fields. It is an implementation issue, not an issue for which codes are listed in the standard. Best regards John Clews -- John Clews, SESAME Computer Projects, 8 Avenue Rd, Harrogate, HG2 7PG tel: +44 1423 888 432; fax: + 44 1423 889061; Email: [log in to unmask] Committee Chair of ISO/TC46/SC2: Conversion of Written Languages; Committee Member of ISO/IEC/JTC1/SC22/WG20: Internationalization; Committee Member of CEN/TC304: Information and Communications Technologies: European Localization Requirements Committee Member of TS/1: Terminology (UK national member body of ISO/TC37: Terminology) Committee Member of the Foundation for Endangered Languages; Committee Member of ISO/IEC/JTC1/SC2: Coded Character Sets