(editor hat on except where noted)
Mark Davis wrote:
>
> MD40
> In this format, all non-initial two-letter subtags are uppercase, all
> non-initial four-letter subtags are titlecase, and all other subtags are
> lowercase.
> =>
> In this format, all two-letter region subtags are uppercase, all script
> subtags are titlecase, and all other subtags are lowercase.
>
> [reason: otherwise forces two/four letter subtags in extensions and
> grandfathered, to have unintended case. Also consistent with other text
> in the RFC about casing.
(and that said: hat off)
I tend to agree. However... I have code that depends on this. Actually,
my code knows about extensions and private-use and doesn't apply the
titlecase or uppercase rules after a singleton. I'd prefer to keep it
that way.
> Note: I think all the grandfathered tags should
> be lowercased, for consistency, since their subtags are not formally
> analyzable.]
True, although they all work correctly.
(retrieves hat, dusts is slightly)
DONE. Therefore, I made an edit so that the casing rules read:
--
In this format, all subtags, including all those following singletons
(that is, in extension or private-use sequences) are in lowercase. The
exceptions to this are: all other non-initial two-letter subtags are
uppercase and all other non-initial four-letter subtags are titlecase.
--
>
> MD41
>
> "de-CH" represents German ('de') as used in Switzerland ('CH').
> =>
> "de-CH" represents German ('de') as used in Switzerland ('CH'), also
> known as Swiss High German. It is distinguished from "gsw-CH", which
> represents Swiss German (Schwyzertuetsch)
DONE. This sort of thing doesn't belong in an example of 'region'
subtags. I changed the example to use 'AT' (Austria) instead.
(hat off)
If you feel strongly that we need to incorporate the de/gsw thing into
an example, let's put it into the section on tag choice.
(hat on)
>
> MD42
> Users MUST NOT assign and use their own subtags, other than private-use
> sequences (such as "en-x-personal") or by using subtags designated as
> private-use in the registry (such as "no-QQ", where 'QQ' is one of a
> range of private-use ISO 3166-1 codes). Otherwise they risk finding
> later that their previously unassigned subtag was assigned a meaning
> that conflicts with their chosen usage.
> =>
> Users MUST NOT assign and use their own subtags, other than private-use
> sequences (such as "en-x-personal") or by using subtags designated as
> private-use in the registry (such as "no-QQ", where 'QQ' is one of a
> range of private-use ISO 3166-1 codes). Not only are they nonconformant,
> they also risk finding later that their previously unassigned subtag was
> assigned a meaning that conflicts with their chosen usage.
NOT DONE (need guidance). I think all of the 'theys' in your suggested
version are confusing. Can you explain your edit? I don't understand
what you're trying to achieve.
>
> MD43
>
> The IANA Language Subtag Registry ("the registry") is a machine-readable
> file in the format described in this section, plus copies of the
> registration forms approved in accordance with the process described in
> Section 3.5 (Registration Procedure for Subtags)
> <http://inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#registrationProc>.
> The existing registration forms for grandfathered and redundant tags
> taken from RFC 3066 will be maintained as part of the obsolete RFC 3066
> registry. The remaining set of subtags created by either [RFC4645]
> (Ewell, D., "Initial Language Subtag Registry," September 2006.)
> <http://inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#RFC4645> or
> [registry‑update] (Ewell, D., Ed., "Update to the Language Subtag
> Registry," September 2006.)
> <http://inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#registry-update>
> will not have registration forms created for them.
>
> [Didn't understand the last sentence.]
DONE. The are no registration forms for the items inserted specifically
by RFC 4645 or RFC 4645bis. Since they weren't separately registered,
there are no forms for IANA to archive. This looks awkward here, I note.
Thus, I split the latter part of the para off and edited it to read:
--
<t>Note: The existing registration forms for grandfathered and redundant
tags taken from RFC 3066 have been maintained as part of the obsolete
RFC 3066 registry. The subtags added to the registry by either <xref
target="RFC4645"></xref> or <xref target="registry-update"></xref> do
not have separate registration forms (so no forms are archived for these
additions).</t>
--
>
> MD44
>
>
> 4.1. Choice of Language Tag
>
> ...
> 5. The same variant subtag MUST NOT be used more than once within a
> language tag.
>
> * For example, the tag "de-DE-1901-1901" is not valid.
>
> [Remove this. This section is on choice, and not validity. Such a tag is
> invalid -- we should not be listing arbitrary conditions from validity
> here.]
DONE. I moved this to Section 2.2.5, where it fits with other usage
requirements for variants.
>
> MD45
>
> Requests to add a prefix to a variant subtag that imply a different
> semantic meaning will probably be rejected.
> =>
> Requests to add a prefix to a variant subtag that imply a different
> semantic meaning SHOULD be rejected.
NOT DONE (need guidance). I think this normative language is
unnecessary, but agree that we need to be fairly clear here. Perhaps we
could change 'probably' to 'usually' or just remove it altogether?
>
> MD46
> The 'und' (Undetermined) primary language subtag identifies linguistic
> content whose language is not known.
> =>
> The 'und' (Undetermined) primary language subtag identifies linguistic
> content whose language is not determined.
NOT DONE (need guidance). Could we say "cannot be determined"?
>
> MD47
> Thus a language tag and its subtags can encompass a very wide range of
> variation and yet remain valid in each particular instance.
> =>
> Thus a language tag and its subtags can encompass a very wide range of
> variation and yet remain appropriate in each particular instance.
> [validity of language tags is formal (2.9), and means something
> different than whether the tag is appropriate for given content. We can
> speak of the "application of a language tag" being valid, or an
> implementation being valid, but need to avoid talking about a language
> tag being valid unless we mean the formal status.]
DONE.
>
> MD48
> Of course, existing content or implementations that use these tags
> remain valid.
> =>
> Of course, application to existing content remains valid, and
> implementations that use these tags remain conformant.
(hat off)
Actually, this example could use either, since we're now talking about
redundant tags---they are both valid and conformant.
(hat on)
DONE. To address this, I changed it thusly:
--
Of course, these tags, where applied to existing content or in existing
implementations, remain valid (all of their subtags are in the registry,
after all), while new tags or applications using these subtags become
possible.
--
======
I have elided MD48 because I need to read it more deeply and suspect it
needs some discussion?
Addison
--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG
Internationalization is an architecture.
It is not a feature.
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.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.