Offline: Registration request for new subtags for Portuguese orthographies
Shawn.Steele at microsoft.com
Tue Mar 24 23:50:34 CET 2015
I hear that "ao1990 is a collection of features that are used from time to time". Presumably it is a different collection of features from "pt". I find that sufficient to be useful for my purposes.
I would like be able to provide a mechanism for content to be tagged as coming from perhaps one set of optional features (pt) or another set of optional features (pt-ao1990).
Should users need finer control over which individual features they need, then other mechanisms may be necessary. If there are truly that many discrete features users may want to choose, that could even be checkboxes on a spell checker.
However that level of detail is not the same as my current problem, which is to be able to make a general distinction between two grossly different variations. For that need, the current proposal would suffice.
Furthermore I don't see how allowing this variant would preclude any future mechanism that would enable the specificity you are expressed concern about. Worst case it seems like this would fall out of use &/or be ignored. (And applications are already expected by RFC4646 to ignore subtags they don't know about).
What I have not heard is any suggestions of alternate solutions that would enable my need to differentiate between multiple variations of Portuguese (pt-PT to be exact) and also address your concerns. I'd be totally happy to entertain any alternative tags that would help me have multiple versions coexist. As far as I personally care it could be pt-alternate (though I imagine others would find that a little too vague).
From: Michael Everson [mailto:everson at evertype.com]
Sent: Tuesday, March 24, 2015 10:54 AM
To: Shawn Steele; Peter Constable; Doug Ewell; joao at silvaneves.org; Andrew Glass (WINDOWS)
Subject: Re: Offline: Registration request for new subtags for Portuguese orthographies
On 24 Mar 2015, at 15:53, Shawn Steele <Shawn.Steele at microsoft.com> wrote:
> I don't think it's helpful to have this part of the discussion offline.
I do, since Peter is still haranguing me about process on the public list. I have tried to suggest to him that that is not the problem, but he keeps going on about it.
> We would find this option useful. I think I understand your concerns, however regardless of whether it is specific enough, I believe that this tag would serve our needs, and the needs of our customers.
Yes. I know. And it is part of my function to occasionally attempt to get people to do better, for the greater good. I have done it before, and successfully.
> From your statements it seems like people choosing this option may not know which of the features they might expect, and so their request may be underspecified.
This is exactly wrong. A user in BR or a user in PT might know exactly what features they prefer. The problem is that this subtag on its own is an umbrella for all the options, and no writer of Portuguese wants his text to wander randomly through the options. This is precisely why I said that "ao1990" is practically identical to a raw "pt", because it's a collection of features which have been used in Portuguese from time to time. What, "fato" and "facto" should just be identical in the spell-checker? That's really not how users expect spell-checkers to work.
So I have asked, and I keep asking: How should this be addressed?
> If another user/software developer does encounter difficulties with underspecificity, I have no problem with future consideration of further subtags that indicate more explicit details about the language's behavior. Then folks could use pt-ao1990-featurex-featurez if needed. (or even pt-featurex-featurez.)
Your reviewer encounters difficulties with underspecificity, and keeps asking proponents of this subtag to address that. This is nothing new. I have raised such questions before many times over the years. Usually people address them and we end up with a positive result.
Michael Everson * http://www.evertype.com/
More information about the Ietf-languages