|
John Clews writes, in response to the current debate:
Michael Everson, quite rightly, is concerned to achieve the effect of
freezing the number of 2-letter codes that are to be used in
implementing RFC 3066.
I agree entirely with this. However, there are details about both
ISO 639:1988 and ISO 639-1 (not yet published but due to be published
during 2001) which mean that what the ISO 639 Joint Advisory Committee
proposed in Washington in February 2000, will pose problems for the
Internet community and in fact all users.
What follows is an attempt to satisfy both apparently opposed groups,
and to find a workable solution for all users of language codes.
It works through suggesting freezing a different animal, at a more
obvious freezing point (1988). This email contains all the details
about what is required (largely as an IETF activity rather than an
ISO activity) to achieve these ends: please study the detail
carefully before rushing to reply.
In passing, Michael also pointed out that:
> I am cc:ing the IETF languages list for the first time on this. I am
> sure that many of them will be extremely unhappy to hear that members
> of the JAC are working to scupper what we understood to have been a
> very good deal.
This is fine: there is only the practical issue of triplication of
emails in some cases, for some users. Is it worth holding the
discussion only on the IETF languages list <[log in to unmask]>,
at least initially, and others joining that list as necessary?
In message <[log in to unmask]> Michael Everson writes
Re: (iso639.276) AW: (2 of 3) Reply: adding more 2-letter codes
> At 09:17 +0100 2001-02-27, Håvard Hjulstad wrote:
>
> > Having been through all the items in the alpha-3 list that would
> > be blocked from inclusion in the alpha-2 list if we stick to the
> > freeze option, I must say that I agree that it is artificial and
> > undesireable not to add new alpha-2 identifiers after the publication
> > of 639-1.
Michael Everson wrote in reply:
> For a certain set of identifiers currently used in internet language
> tagging. The point being, for heaven's sake, if you want to add two
> letter identifiers for those particular items, do so now, and then
> keep to the promise/agreement/resolution the JAC made.
>
> The alternative is to destabilize the usefulness of ISO 639 for
> internet use, because we will have to then go and rewrite the RFC
> again
There is opposition to freezing ISO 639-1 from the representatives of
at least three national member bodies of ISO/TC37 (Terminology) who
have been active in development of ISO 639-1, because
(a) ISO 639-1 has different criteria for adding new codes to the
criteria in ISO 639-2;
(b) in some programming languages and applications, the use of _only_
2-letter codes for languages seems to have been built into the
system design, and overcoming this limitation, and coping with
backwards compatibility, is NOT a trivial task.
These are not simply "pie-in-the-sky theoretical considerations" as
Michael Everson suggests, later in his email.
Discussion so far has not outlined any ways of overcoming the
problems outlined above. This email outlines some practical
proposals.
I think that RFC 3066 _WILL_ have to be rewritten to reflect this
exact point. Not doing so will make for all sorts of confusions.
It can be done in a way which will keep work to a minimum.
Simply rewriting RFC 3066, to refer only to ISO 639 (2-letter codes)
and to ISO 639-2 (3-letter codes), and simply reassigning a small
number of codes as 3-letter codes from ISO 639-2, in place of the (as
yet unpublished) ISO 639-1, seems to be much the simplest solution,
and I am happy to suggest small amendments to RFC 3066 which would
enable this to be done.
RFC 3066 should state that ISO 639:1988 is frozen. ISO 639-1 (as yet
unpublished) should not be refered to in RFC 3066.
It will take very little rewriting of RFC 3066 to make it work:
instead of refering to ISO 639-1 for 2-letter codes, refer simply to:
ISO 639:1988 (E/F) - Code for the representation of names of
languages - The International Organization for Standardization,
1st edition, 1988-04-01 Prepared by ISO/TC 37 - Terminology
(principles and coordination).
As I recall, freezing 2-letter codes in Internet use at this point
(ISO 639:1988) was Michael Everson's _original_ proposal, prior to
his later proposal of freezing ISO 639-1 2001 (not yet published):
the Internet community should not tie itself to yet unpublished
standards, a position which RFC 3066 currently gets quite near,
as it stands now.
There will be a need for IANA to reassign some language tags, and
deprecate others, but this has already been done for some of these
tags, as can be seen from the IANA website.
The examples at the end of this email also follow the pattern of
the IANA website.
It may also be worthwhile to ensure that the only 2-letter codes from
any part of ISO 639 which would be used in implementing RFC 3066 are
those in the published text and tables of ISO 639:1988, and not any
further amendments by the ISO 639 Maintenance Agency between 1988 and
2001.
NB: this would have the effect of freezing which Michael Everson, quite
rightly, is concerned to achieve.
In particular, the following tags (and only those tags) which would
have not yet received much use, would need to be rewritten, and to go
through the IANA Language Tag registration process.
Tag Description Reference Notes
------- ----------------------------- --------- ---------
no-bok Norwegian "Book language" Deprecated: use
ISO 639-2 nob,
registered Feb.
18, 2000
[ALSO ADD]
nb Norwegian "Book language" Deprecated: use
ISO 639-2 nob,
registered Feb.
18, 2000
[Note nb -> nob changes in both Notes on Deprecation above]
no-nyn Norwegian "New Norwegian" Deprecated: use
ISO 639-2 nno,
registered Feb.
18, 2000
[ALSO ADD]
nn Norwegian "New Norwegian" Deprecated: use
ISO 639-2 nno,
registered Feb.
18, 2000
[Note nn -> nno changes in both Notes on Deprecation above]
i-navajo Navajo [Burke] Deprecated: use
ISO 639-2 nav
[remove text
"registered Feb.
18, 2000"]
[ALSO ADD]
nv Navajo [Burke] Deprecated: use
ISO 639-2 nav
[remove text
"registered Feb.
18, 2000"]
[Note nv -> nav changes in the Note on Deprecation above]
i-lux Luxembourgish [Wimmer] Deprecated: use
ISO 639 ltz
[remove text
"registered Sept.
9, 1998"]
[ALSO ADD]
lv Luxembourgish [Wimmer] Deprecated: use
ISO 639 ltz
[remove text
"registered Sept.
9, 1998"]
[Note lv -> ltz changes in the Note on Deprecation above]
I look forward to any further comments which aim to achieve a
solution to this.
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 ISO/TC37: Terminology
|
