There might be geographical issues as well, and not only language. Or rather, if the language also have a geographic tag (that I do not remember what its name is) then it might be complete.
Example, in French, one do not have accents on the capital letters (well, one
have if it is needed due to distinguish between words, if it is a name etc --
so it is optional), but do in Canada. Of course, one can say maybe that French
in France is one language and French in Québéc is another, but...
You get the point.
So, I agree with you that one should probably treat the word "language" as only
one example of a parameter in the "locale" definition that changes the
behaviour of the function.
Patrik
On 12 Jun 2015, at 1:04, Peter Saint-Andre - &yet wrote:
> With my document shepherd hat on, I just reviewed draft-ietf-precis-mappings.
> I have sent some editorial comments to the authors. I also found two more
> substantive issues...
>
> 1. The "local case mapping" method specified in Section 2.3 talks about
> locale and context. However, the example in the second paragraph is a matter
> of language, not locale:
>
> As an example of locale and context-dependent mapping, LATIN CAPITAL
> LETTER I ("I", U+0049) is normally mapped to LATIN SMALL LETTER I
> ("i", U+0069); however, if the case of Turkish (or one of several
> other languages), unless an I is before a dot_above, the character
> should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131).
>
> As I understand it, locale (see Section 8 of RFC 6365) would refer to a
> particular region within a language-speaking community, such as Switzerland
> within the German-speaking areas.
>
> The SpecialCasing.txt file in the Unicode standard talks about
> language-sensitive mappings for the Lithuanian, Turkish, and Azeri languages.
> (It also talks about a language-insensitive mapping, i.e., context-dependent
> mapping, for Greek final sigma.) It does not talk about locale-dependent
> mappings for particular regions within any language-speaking communities.
>
> Therefore, I wonder if all mentions of locale in draft-ietf-precis-mappings
> really ought to be mentions of language. On reading the text in the document
> right now, I provisionally concluded that this switch would make sense, but I
> haven't thought carefully about every instance. And I would be curious to
> hear from the authors and working group about this issue.
>
> 2. Appendix B purports to describe why local case mapping needs to be an
> alternative to Unicode Default Case Mapping instead of being applied
> sequentially (the text mentions the possibility of applying local case
> mapping before Unicode Default Case Mapping - is that the only option, or
> should we say something about applying it after?).
>
> However, Appendix B only mentions eszett (U+00DF) and to my mind does not
> provide a complete argument for why local case mapping needs to be an
> alternative to Unicode Default Case Mapping. At the least, it might be
> valuable to mention the handling of characters other than eszett. I suppose
> the basic argument is already in Section 2.3, but if so then I think that
> Appendix B might have a misleading title.
>
> Other than these two issues, I think the document is in good shape (modulo
> some editorial adjustments).
>
> Peter
>
> --
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> precis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/precis
signature.asc
Description: OpenPGP digital signature
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
