Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

["Asmus Freytag (c)" <[e-mail]>]

On 12/7/2018 12:02 PM, John C Klensin wrote:
>
> --On Friday, December 7, 2018 11:28 -0800 Larry Masinter
> <[e-mail]> wrote:
>
>> ...
>> The reason for emphasizing transcription is not that there
>> aren't other operations that are possibly more frequent
>> (copy/paste a URL from one context to another, remember on a
>> bookmark list) but rather that transcription is the most
>> stringent requirement – if a user can transcribe a name
>> resulting in the same sequence of Unicode codepoints, then
>> they can display the name, distinguish the name from other
>> (transcribable) names.
> Larry, I hope Asmus will respond further to this because he is
> far more expert on relevant issues across a very wide range of
> scripts and writing systems than I am, but I don't believe what
> you write above is true.

Globalization is often misunderstood - it's neither the magic bullet that
makes everything equally accessible to everyone, nor is it exclusively
about presenting everything to every user in their native context.

Instead, it's an interesting mixture of both.

For IDNs the goal is to allow full native support of mnemonic identifiers
in the context of the language/script native to the user - for all such
combinations of languages and scripts so that, in principle all users
can be supported.

But it's also about enabling the accessing of resources outside your
native bubble - Unicode is a big step in that direction, because before it
you were often locked into a native character set baked into your system.

However, a label in a foreign script will not be "mnemonic" for you,
and there's nothing we can do about that in this context. However,
we should expect that labels in your script (and where relevant your
language) are indeed able to be mnemonic.

Otherwise, why not use digits like telephone numbers?

I think that is ultimately what Larry has in mind and what I cover by
"typable". You should be able to read a label, understand it, and
reproduce it by typing, or be able to tell someone about it.

For the Latin script (because of the features that you are attempting
to outline below) even arbitrary sequences of code points do not
generally compromise the ability for a label to be mnemonic and to
support dealing with it other than by clicking/pasting.
(The above is strictly true only for ASCII, once you add the full range
including combining marks a bit more care must be taken - as will
be evident when the draft for the Latin Root Zone LGR becomes
available, until then, I'll spare myself the digression into details)

For other scripts, there's a wide variety of issues.

One example from Arabic: Quite a few letters in Arabic share positional
forms, that is, they are only distinct if, for example, at the end of a 
word.

Also, some languages using the Arabic script support keyboards that
only have one of these letters, but not the "standard" Arabic-language
one. As a result, while users can "read" an Arabic-language name,
a geographical name, for example, they could not type that name.
If they did, it may even look right, but be different.

Therefore, a registry that attempts to support both languages in
the Arabic script, but does not support variants, will have a fraction
of its labels that are de-facto unusable for some users.

Understood in that sense, "typable for a native user" is a valid goal
that informs necessary features of label generation rules (registry
policies) that enable the use of labels as mnemonic, in the same
way we take for granted for non-IDN labels.

A./

>   Some scripts --of which the Roman
> Script (Basic Latin of some millennia ago) is a good example--
> simply have characters that are more easily distinguishable from
> either other by people who cannot actually read the script or
> associated language(s) that others.  Put a hypothetical person
> who has never seen either before in front of a short string of
> characters in that script and in front of a script written with
> connected characters, complex use of ligatures, and subtle
> distinctions among characters (look at Arabic digits for two and
> three for an example of what I mean by "subtle" ... or look at
> "O" and, in many contemporary type designs, "Q").  Then supply
> that person with character pickers for the two scripts.  You
> would almost certainly get accurate transcription of the Roman
> characters and probably would not get it with the other script.
> In neither case would be ability to transcribe imply the ability
> to render and display (I'd encourage observation of five and six
> year olds learning to write), nor would it imply that ability to
> accurately copy and paste.
>
> So, ability to transcribe may be a useful goal, but it isn't,
> IMO, close to Patrik's global requirements list.
>
> best,
>     john
>
>
>
>