In message <001901c37dcb$4667b2a0$0a01a8c0@[log in to unmask] writes:
> I think we all know the basics on the linguistic side of the story.
> There is clearly also a political side to this story, which isn't at
> all clear to me in all detail.
> The important point in my opinion is that we don't for 639-1 or 639-2
> have a very clear policy on how to "weigh" linguistic vs political
> issues, nor how to "weigh" the different linguistic issues (relating
> to written and spoken language).
And for that reason (we've never had it before, because we've never
needed it before) there's no need to introduce a new principle
(dealing with "variants") just for once special case.
Introducing a "new principle" along with special cases always causes
problems later, in my experience, in many different situations.
In passing, you also wrote:
> Actually even geography comes into
> this. "Valencian isn't a variant of Catalonian, because Valencia
> isn't a part of Catalonia". Had there happened to be a "Catalencian"
> region the story might have been different.
Catalan (the Balearic varities) are also spoken in the
Balearic Islands, so that example's a slight red herring.
This isn't the main part of my reply, but you might as well say that
'"Canadian English isn't a variant of English, because Canada isn't a
part of England". Had there happened to be a "CanEnglish" region the
story might have been different.'
Language and Country, and Language and Province (or county, or state)
don't have neat 1:1 relationships, as we know.
What follows is the main part of my reply: you also wrote:
> The basis for raising the issue at this time was interesting: There
> may be a need to localize software to Valencian as opposed to
> Catalonian; on the other hand most libraries throughout the world
> will not have a need to distinguish. Different users have different
> needs. The "ISO 639 family" needs to be developed into something that
> is flexible enough and precice enough to satisfy different needs.
Not so. I agree that _something_ needs to be developed into something
that is flexible enough and precice enough to satisfy different
However, does that need to be ISO 639-2?
That something could well be RFC 3066 rather than ISO 639-2.
RFC and subsequent registrations exist for that very
purpose, and are used in that way.
For an English-language variant, RFC 3066 provides en-scouse.
For a Catalan-language variant, RFC 3066 could provide ca-valencian,
as Michael Everso has already suggested.
RFC 3066 meets the needs you mention. There's no need to amend
ISO 639-1 or ISO 639-2, which is what the previous email suggested.
Keytempo Limited (Information Management),
8 Avenue Rd, Harrogate, HG2 7PG
Tel: +44 1423 888 432
mobile: +44 7766 711 395
Email: [log in to unmask]