On 2/12/15 2:10 PM, Peter Saint-Andre - &yet wrote:
On 2/12/15 8:50 AM, Pete Resnick wrote:
On 2/11/15 7:59 PM, Peter Saint-Andre - &yet wrote:
One thing that bothers me here is that we're not providing actionable
guidance to the vast majority of non-delusional profile authors. Are
we saying that it's not a good idea to say anything about
directionality at all?
In my mind there are two possibilities that a profile author ends up
with:
1. My application doesn't care whether the strings I'm using appear
differently in different contexts. If a string looks one way to a person
on a LTR system and a different way to a person on an RTL system, that's
fine. I don't care what order the characters appear (for instance, if
numerals appear before or after punctuation).
or:
2. I want my strings to appear consistently. Numerals appearing on one
side of a dot on an LTR system and on the other side of a dot on an RTL
system would be a really bad thing.
If 1, your profile should say, "Directionality Rule: None".
If 2, then you want "Directionality Rule: Something", and unless you
have some magic specialized knowledge (that you don't, trust us), you
want "Directionality Rule: 5893". And, BTW, you had better be basing
things on IdentifierClass; 5893 is *not* sane if you're basing on
FreeformClass, and you probably meant to give answer #1 above.
Do we agree that the above is what the WG is saying?
That seems reasonable.
If so, does the text capture that?
Not quite. We capture the conclusions but not the reasoning. Let me see
if I can formulate some text...
Here you go...
###
5.2.5. Directionality Rule
The directionality rule of a profile specifies how to treat strings
containing what are often called "right-to-left" (RTL) characters
(see Unicode Standard Annex #9 [UAX9]). RTL characters come from
scripts that are normally written from right to left and are
considered by Unicode to, themselves, have right to left
directionality. Strings containing RTL characters often also contain
"left-to-right" (LTR) characters, such as numerals, as well as
characters without directional properties. Consequently, such
strings are known as "bidirectional strings".
Presenting bidirectional strings in different layout systems (e.g., a
user interface that is configured to handle primarily an RTL script
vs. an interface that is configured to handle primarily an LTR
script) can yield display results that, while predictable to those
who understand the display rules, are counter-intuitive to casual
users. In particular, the same bidirectional string (in PRECIS
terms) might not be presented in the same way to users of those
different layout systems, even though they are consistent within any
particular layout system. In some applications, these presentation
differences might be considered problematic and thus the application
designers might wish to restrict the use of bidirectional strings by
specifying a directionality rule. In other applications, these
presentation differences might not be considered problematic (this
especially tends to be true of more "free-form" strings) and thus no
directionality rule is needed.
The PRECIS framework does not directly address how to deal with
bidirectional strings across all string classes and profiles, and
does not define any new directionality rules, since at present there
is no widely accepted and implemented solution for the safe display
of arbitrary bidirectional strings beyond the Unicode bidirectional
algorithm [UAX9]. Although rules for management and display of
bidirectional strings have been defined for domain name labels and
similar identifiers through the "Bidi Rule" specified in the IDNA2008
specification on right-to-left scripts [RFC5893], those rules are
quite restrictive and are not necessarily applicable to all
bidirectional strings.
The authors of a PRECIS profile might believe that they need to
define a new directionality rule of their own. Because of the
complexity of the issues involved, such a belief is almost always
misguided, even if the authors have done a great deal of careful
research into the challenges of displaying bidirectional strings.
This document strongly suggests that profile authors who are thinking
about defining a new directionality rule think again, and instead
consider using the "Bidi Rule" [RFC5893] (for profiles based on the
IdentifierClass) or following the Unicode bidirectional algorithm
[UAX9] directly (for profiles based on the FreeformClass or in
situations where the IdentifierClass is not appropriate).
###
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
