Dear Peter and also Addison, > > > 6. Redundant script tags which are the same as the suppressed script > > for a language are not present. > > IIUC, you're saying that a canonical tag won't have a script subtag if that subtag is given in the Suppress-Script field in the subtag record for the language subtag used in that tag. (E.g., suppose language subtag 'aa' has Suppress-Script: 'Bbbb'; then tags of the form "aa-(xxx-)Bbbb..." are not canonical.) Is that right? Yes, as per 3.1.8 which says that tags SHOULD NOT specify the script if it is the same as a suppressed script. > Two problems: first, you don't suggest how to produce a canonical equivalent for any given tag. How about: 6. A script subtag that is the same as the suppress-script script subtag for the language MUST be removed. >Secondly, while "en-Latn" is not generally recommended, there may be application scenarios in which it is appropriate, perhaps used in contrast to something like "en-Hang", in which case the canonical form should include the normally-suppressed script subtag. ? What's wrong with "en-Hang" and "en" in that case? Are we saying that something that one part of the standard says you SHOULD NOT do is still considered appropriate for a canonical tag? If you want to be very explicit nobody is saying you CANNOT use "en-Latn" just that it isn't canonical. > > bru-Latn-fonipa > > > > or can we in some way indicate the implication of Latn by fonipa and > > just use: > > > > bru-fonipa > > By that line of reasoning, the canonical form for "fr-1694acad" could be simply "1694acad" -- except that that's not even well formed. You could remove script or region subtags in deriving a canonical tag if they were specified as the prefix for a variant, but they would have to be the *only* prefix for that variant (else the canonical form wouldn't be deterministic), and you'd end up with a canonical tag that is not valid, and not likely the same as what is used anywhere else. Comparisons would not be any easier, and we couldn't suggest that these canonical forms actually be what gets generated and used in interchange. Yes I'm rapidly going off prefix here :) > That is, if these got a Prefix field and you were eliminating the prefix. Alternatively, I suppose you could allow Suppress-Script or Suppress-Region fields for variant subtags and use that in deriving canonical tags, but that just means adding more machinery. Well it depends whether you want to have redundant information in your tags or a more complex analyser. There's plenty enough machinery in an analyser already and I would suggest that much of it is just as spurious. So what's a little more? :) > Either way, I think this would just get complicated for no particular gain. My inclination would be to say that 'fonipa' should require a prefix of 'Latn' (probably specified as an extended language range "*-Latn"), and always require that script tag be included, even if that seems redundant. It's clear that, in many cases such as "fr-1694acad" or "sl-nedis", we already end up requiring some degree of redundancy in the tag; I don't see a problem doing that in these cases. I don't have a problem with this, although it's different from what I have been told regarding fonipa before that said that the Latn can be implied. So which is canonically correct: en-fonipa (Latn removed by suppress script on en) or en-Latn-fonipa (since *-Latn is the prefix for fonipa)? > But there's the rub: we'd be saying in one place that prefix SHOULD be included in tags with the given variant, but in another place that they not be used in the canonical form, and that the caonical form SHOULD be used. Not very self-consistent. I agree, and withdraw the Prefix hack suggestion. So there are choices before us: 1. Add Prefix: *-Latn and probably require en-Latn-fonipa 2. Add Suppress Script: Latn to a variant and increase complexity slightly but I think, that would solve the whole issue relatively simply. 3. Do nothing and allow en-fonipa but bru-Latn-fonipa Yours, Martin _______________________________________________ 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.