[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ltru] Re: FW: tags for written or spoken content, was Swiss german, spoken



McDonald, Ira wrote:

> Many people may have seen this note from Tex Texin to the
> IETF Languages list

Yes.

> the _entire_ justification for shoehorning 'script' between
> 'language' and 'region' is the overwhelming focus on
> traditional uses of language tags for _written_ content.

No, I don't think that that's a correct description of the
"entire justification", it meshes two independet aspects.

For written content we need the script, only the language is
not good enough.  So we either need something like Bruce's
Content-Script, or where that's no option we try to add it to
the existing language tag.

If we do the latter we could add it in theory everywhere, in
position 1, 2, 3, or at the end of a language tag.

Each way has its advantages and disadvantages wrt matching
and backwards compatibility.  E.g. if we'd add the script in
the first position it's guaranteed to be incompatible with
all 3066-applications, that might actually be a good thing.

If we decide to add it elsewhere I fail to see any advantage
of the 3rd position (between region and variant).  So we take
either the last or the 2nd position.

If we assume that LTR matching and RTL truncation is the most
natural way to process tags, the 2nd position is probably the
best choice (in relation to 3rd / last position).

 From my POV it's not necessarily better than the other ideas,
1st position or no script at all in language tags.

> A much cleaner solution remains to push 'script' back where
> it belongs in medium-neutral language tags --> after the
> 'region' code.

That's the 3rd or last position,  I don't see any advantage
of the 3rd position, en-Latn-US-boont or en-US-Latn-boont are
both ugly.  Maybe en-US-boont-Latn would be a good idea.

But actually the region codes were already a dubious idea.
If I could just start from scratch I'd kill them - if the
region is important register it as variant.

A less radical idea would be "either region or variant, but
never both at the same time".  Then we'd probably discuss a
language-( region / variant )-script scheme.

My point is, the new "unloved script" isn't the real problem.
The real problem is the legacy region.  And we're damned to
keep it - without looking into the LTRU charter I fear that's
what it says.
                          Bye, Frank



_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.