Re: [Ietf-languages] Suppress-Script, assumptions, and guesses (was: RE: Suggestion to update Urdu Script Designation in the subtag registry)

[Richard Wordingham <[e-mail]>]

On Fri, 14 Aug 2020 10:32:07 -0600
"Doug Ewell" <[e-mail]> wrote:

> Richard Wordingham wrote:

> If the content already exists, and one has retrieved it, and the
> language tag doesn't reveal the script, one can figure out what
> script it is written in by inspecting the content. This is just like
> the mechanic inspecting the car to figure out how many wheels it has.

The "various texts cluttering my house" aren't all in the same room
as one another.  To inspect the text, I would have to get it out from
its location, which could require a sequential search through a
document wallet.  (Perhaps random access would be possible after the
indexing exercise.)

> I confess that I don't understand this exercise.

> > I was coming to the conclusion that the ambiguity between "en" for
> > "en-Latn" and "en" for "English, but I won't tell you the script",
> > was resolved by the tags Zxxx, Zyyy and Zzzz.  Then the latter
> > meaning for text gets translated to en-Zyyy, and then the
> > abbreviation of en-Latn to en is resolved by the suppress-script.  
> 
> 'Zxxx' is a different animal: "Code for unwritten documents" from ISO
> 15924 is interpreted here to mean that this content is not written.
> It doesn't necessarily mean that the language of this content is
> never written.

Yes, I'd figured that this would handle audio CDs if I were including
them in the index.  It would also cover pure pictures.

> If I tag textual content as "en", I am not saying anything about the
> script. I am leaving it up to you, the recipient of the content, to
> figure out what the script is. Because it is English, the great
> likelihood is that the script is Latin. One way to find out would be
> to inspect the content.

Not easy.  And even if the material were online, determining the script
of a bit map is not always straightforward.

> Alternatively, you COULD go to the Registry and look at the
> Suppress-Script value of 'Latn' to give you a strong hint that the
> text is in Latin script. But that is not a guarantee; "en" is also a
> perfectly valid tag for English written in Runic. 

I do have some en-Runr-NZ stuff!

> If I tag it as "en-Latn", I am explicitly saying the script is Latin.
> I would hope that I am doing so for a reason, and not just adding a
> script subtag automatically because I didn't read Section 4.1. Maybe
> I am anticipating that readers will call into question whether the
> text is in Latin script, and need to know without looking at the
> content.

I thought we'd already agreed that this was the correct solution in my
case.

> If I tag it as "en-Zyyy", that implies that I, the tagger, don't know
> what script it is in. It seems unlikely to me that I would know a
> text is in English but don't know the script.

The mechanism I had in mind is to read the cover and not look at the
content.  It's not very likely, but not impossible.  I also
deliberately didn't mention the complication of different paragraphs
having different language-script combinations.

> I'm skipping over the remainder, which continues to claim that not
> using a script subtag for languages overwhelmingly written in a
> single script creates problematic ambiguity. We have heard very
> little in the past 15 years that either Suppress-Script or the
> overall philosophy of "tag content wisely" has greatly compromised
> the usefulness of BCP 47 tags. Maybe people just aren't telling us.

I did point that usually whatever process needs to know the script of
some text can look at the text itself, and wouldn't bother about any
label.  That knowledge is usually required at a lower granularity than
the labelling would naturally be applied at.

However, there may be cases where 'likely tags' are being used, so that
'en' just gets translated to 'en-Latn'.  If that process goes wrong,
the most likely response is advice to specify the script, implying that
'en' on its own would be wrong for 'en-Thai'.
  
Richard.