Re: [ltli] Responded to Mark Davis's comments (exchanged privately). (#12)

Although there are certain key differences between how a bcp47 language
subtag would be interpreted as a language tag as distinct from a locale
identifier. For instance when working with language in the Dinka language,
we tend to use the "din"sibtag since the content we are working with is
cross-dialect content. But as a locale tag, it means something different,
cldr equates it with a specific dialect group, rather than as a macro
language.

I understand what the purpose of the text is, but it muddies the waters.

On Tue, 14 Jul 2020, 02:23 Addison Phillips <notifications@github.com>
wrote:

> *@aphillips* commented on this pull request.
> ------------------------------
>
> In index.html <https://github.com/w3c/ltli/pull/12#discussion_r453772049>:
>
> > @@ -280,11 +283,13 @@ <h2>Best Practices and Recommendations</h2>
>
>          <p>Checking if a tag is <a>valid</a> requires access to or a copy of the registry plus additional runtime logic. While content authors are advised to choose, generate, and exchange only valid values, language tag matching and other common language tag operations are designed so that validity checking is not needed. Features or functions that need to understand the specific semantic content of subtags are the main reason that a specification would normatively require <a>valid</a> tags as part of the protocol or document format.</p>
>
> +        <p class="advisement" id="ltli-canonical-req"><a class="self" href="#ltli-canonical-req">&#x200B;</a>Content authors and implementations SHOULD use language tags that are <a>canonical Unicode locale identifiers</a> and SHOULD normalize language tags that they consume using the rules for producing canonical tags.</p>
>
> The intention here was to avoid having a normative requirement placed into
> specifications. Mark commented that it would be best if the language tags
> found in the wild conformed to LDML's normalization requirements (which, it
> happens, are also what ECMA-402 is doing). So this is an advisement about
> that primarily.
>
> The contents of the -t and -u extensions I intend to be opaque to most
> content authors/implementations. But the additional canonicalization and
> tag choice rules in Sections 3.2 and 3.3 of TR35 are probably a good idea
> for content authors and implementations to hew to. The use of MAY is too
> weak. SHOULD is probably right, but, to your point, seems overly
> prescriptive.
>
> I should probably break this into two best practices: one for content
> authors and one for implementations. Let me try that next. Would appreciate
> your thoughts on how to address...
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/ltli/pull/12#discussion_r453772049>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AALGM64C6767SYJOCZFAJ2DR3MYHRANCNFSM4OXLNUYQ>
> .
>


-- 
GitHub Notification of comment by andjc
Please view or discuss this issue at https://github.com/w3c/ltli/pull/12#issuecomment-658146877 using your GitHub account

Received on Tuesday, 14 July 2020 12:18:39 UTC