Subject: [Ltru] 2nd WG last call: lower-case may/should/must

From: Martin Duerst <[email-masked]>
Date: Tue, 16 May 2006 19:07:29 +0900

These are the lower-case may/should/must in the main text that
I found. There is no IETF rule that forbids these that I'm aware
of, but as we tried hard to avoid them, we can as well do the
full job. If not, we can as well change back many 'might's to
simple 'may's.

    A speaker of Breton in France, for example, may specify
    "br" followed by "fr", meaning that if Breton is available, it is
    preferred, but otherwise French is the best alternative.  It can get
    more complex: a user may wish to fall back from Skolt Sami to
    Northern Sami to Finnish.

    may specify -> can specify
    may wish to -> wants to

    When working with language ranges and matching schemes, there are
    some additional points that may influence the choice of either.

    may -> can

    Filtering seems to imply that there is a semantic relationship
    between language tags that share the same prefix.  While this is
    often the case, it is not always true and users should note that the
    set of language tags that match a specific language range do not
    necessarily represent mutually intelligible languages.

    change " and users should not that" to ": ".

    Also, while at it, change "the set of language tags that match"
    to "the language tags that match", to make this match with "do"
    later in the sentence. The result of these edits would be:

    Filtering seems to imply that there is a semantic relationship
    between language tags that share the same prefix.  While this is
    often the case, it is not always true: the language tags that match
    a specific language range do not necessarily represent mutually
    intelligible languages.

    Whether a subtag adds distinguishing value can depend on the context
    of the request.  For example, a user who reads both Simplified and
    Traditional Chinese, but who prefers Simplified, might use the range
    "zh" for filtering (matching all items that user can read) but "zh-
    Hans" for lookup (making sure that user gets the preferred form if
    it's available, but the fallback to "zh" will still work).  On the
    other hand, content in this case should be labeled as "zh-Hans" (or
    "zh-Hant" if that applies) for filtering, but for lookup, if there is
    either "zh-Hans" content or "zh-Hant" content, then one of them (the
    one considered 'default') should also be available under a simple
    "zh".

    should be labeled -> preferabily is labeled
    should also be available -> preferably also is made available

    Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN-
    MINUS (%x2D).  Language ranges also use the character ASTERISK
    (%x2A).  These characters are present in most character sets, so
    presentation or exchange of language tags or ranges should not be
    constrained by character set issues.

    should not be -> is not

    Lookup produces the single result that best matches the user's
    preferences from the list of available tags, so it is useful in cases
    in which a single item is required (and for which only a single item
    can be returned).  For example, if a process were to insert a human
    readable error message into a protocol header, it might select the
    text based on the user's language priority list.  Since the process
    can return only one item, it must choose a single item and it must
    return some item, even if none of the content's language tags match
    the language priority list supplied by the user.

    must -> has to (twice)

    Very special thanks must go to Harald Tveit Alvestrand, who
    originated RFCs 1766 and 3066, and without whom this document would
    not have been possible.

    [I can live with that, since it's clearly outside the normative
     part of the spec.]

Regards,     Martin. 

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Tue, 16 May 2006 09:08:17 -0400

> full job. If not, we can as well change back many 'might's to

As before, anything omitted is a simple +1.

>    may specify -> can specify

+1 on the first, but -1 on the second: omitting "may" altogether
makes the sentence into a factual claim rather than a hypothetical one.
"Might" is probably the best bet here.

>    should also be available -> preferably also is made available

-1.  Clunky.  For the first, use "ought to be labeled"; for the second,
use "also ought to be available.

>    the language priority list supplied by the user.

"Needs to" makes the process less human and is preferable.

-- 
You're a brave man! Go and break through the            John Cowan
lines, and remember while you're out there              [email-masked]
risking life and limb through shot and shell,           http://ccil.org/~cowan
we'll be in here thinking what a sucker you are!
        --Rufus T. Firefly

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 16 May 2006 14:33:18 -0700

More comments...

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]]
> Sent: 2006?5?16? 3:07
> To: LTRU Working Group
> Subject: [Ltru] 2nd WG last call: lower-case may/should/must
> 

I did this (which you'll hate for its "might"):

--
A speaker of Breton in France, for example, can specify "br" followed by
"fr", meaning that if Breton is available, it is preferred, but otherwise
French is the best alternative. It can get more complex: a different user
might want to fall back from Skolt Sami to Northern Sami to Finnish.
--
>     some additional points that may influence the choice of either.

Done.
>     a specific language range do not necessarily represent mutually

Done.
>     should also be available -> preferably also is made available

This was changed in response to the last message (and not according to this
precise suggestion).
>     constrained by character set issues.

Uh... this text is exactly the same as that in 3066bis... and is almost an
exact quote from RFC 3066:

--
Language tags may always be presented using the characters A-Z, a-z,
   0-9 and HYPHEN-MINUS, which are present in most character sets, so
   presentation of language tags should not have any character set
   issues.
--

>     the language priority list supplied by the user.
I implemented this slightly differently:

--
Since the process can return only one item, it is forced to choose a single
item and it has to return some item, even if none of the content's language
tags match the language priority list supplied by the user.
--
>     [I can live with that, since it's clearly outside the normative
I could elide the "must", but I like the emphasis.