On 10/09/2013 07:42 PM, "Martin J. Dürst" wrote:
On 2013/10/10 6:05, Peter Saint-Andre wrote:Here is proposed text (for the end of section 9.5): The challenges inherent in supporting the full range of Unicode codepoints has in the past led some to hope for a way to programmaticallynegotiate more restrictive ranges based on locale, script, or other relevant factors. As a general-purpose internationalization technology, the PRECIS framework does not include such a negotiation mechanism.Mostly fine up to here, except that in this area, not only negotiation mechanisms, but also augmenting the identifiers themselves with language/locale information are regularly wished for. Using a specific example, that chat[English] and chat[French] would be two separate identifiers. We should also clearly warn against this.Applications requiring a tighter binding to the user'slinguistic environment might need to develop extensions to the PRECISframework, or special-purpose internationalization technologies.I don't like this, because it essentially says "we don't do this, but you may well want to do it". It's something that makes a lot of sense e.g. in a content management system. But it does not make sense, and we shouldn't give the impression that it does, in the context of identifiers and similar stuff (even the PRECIS "FreeformClass" is about identifiers, not about content.
You make several good points. How about this? The challenges inherent in supporting the full range of Unicode code points have in the past led some to hope for a way to programmatically negotiate more restrictive ranges based on locale, script, or other relevant factors, to tag the locale associated with a particular string, etc. As a general-purpose internationalization technology, the PRECIS framework does not include such mechanisms. Peter _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
