Request to register private-use variant subtags

[Gordon P. Hemsley]

Doug et al.,

I meant to continue that discussion, but I've been a little busy
lately. I may as well respond here instead.

An important part of what I'm doing involves a step once-removed
between the Registry and the display of the names.

As you well know, many entries in the Registry contain multiple values
for the "Description" field. This may because things have different
names or whatever. So the first step of what I'm doing involves
deciding how to translate Descriptions into Names. (They are not the
same thing—the registry has no concept of Name.)

In this process, Private Use subtags are handled specially. Since, as
far as I can tell, such subtags have special semantics—in particular,
that the Registry has no knowledge of their meaning—they do not
receive a Name. In fact, they are excluded from my database as any
"unregistered" subtag would be. As such, both a private-use subtag and
an unregistered would be displayed literally in my system. Only
subtags with corresponding Names in my database are processed before
being displayed.

So that is step 1.

The problem comes when I want to test that the code is doing what I
described above. In order to ensure that I get a clear and permanent
separation between a subtag that gets a display name and a subtag that
gets output literally, I use private use subtags—they are permanently
reserved, so I don't run the risk of them accidentally getting an
associated Name in the future.

And this system works fine for language, region, and script subtags.
It falls apart when it comes to variant subtags. There is no clear
separation between a subtag that should have a display name and which
should get output literally—they all potentially fall into the former
category. A subtag that "probably won't be registered" is not a
concrete enough definition. Without formally and permanently reserving
some variant subtags for private use, there will always be the
possibility of any given subtag of being registered as a real variant.
(The word of those currently involved that they'd never approve such a
subtag is not good enough. Things change.)

The only way to guarantee that a variant "will almost certainly never
be registered" is to permanently and officially reserve it as such.

I hope this helps to explain my situation more clearly. At the very
least, I hope it shows that my claims are neither strange nor unusual.

Gordon

On Sat, Apr 7, 2012 at 1:54 PM, Doug Ewell <doug at ewellic.org> wrote:
> CE Whitehead <cewcathar at hotmail dot com> wrote:
>
>> I tend to concur with Doug, that rather than registering the whole set
>> of gxaaa  - qx999999 variant codes, one would need to redo RFC 5646,
>> and include the information about the new reserved codes in that
>> document.
>>
>> I am unsure as to whether a variant like qxqxqxqx or qzqzqzqz could be
>> registered for this purpose.
>
>
> After discussing Gordon's use case with him privately, I am more convinced
> than ever that no action is needed on the part of either this list or LTRU,
> either to add a subtag (or range of subtags) or to update BCP 47.
>
> Gordon wants to unit-test his code against a variant subtag value that is
> not listed in the Registry. (Perhaps strangely, he is regarding the existing
> language, script, and region private-use subtags as "not listed in the name
> database," though of course they are.)
>
> The solution, for unit-testing purposes, is simply to pick a subtag value
> that is not registered, ideally one that is unlikely ever to be registered,
> and optionally to verify as part of his unit test that the subtag is not
> registered. That was Addison's point in saying "A subtag like "qxqxqxqx" is
> a pretty good bet"—not as something that should be registered, but on the
> contrary, as something that will almost certainly never be registered.
>
> Does anyone else think any action needs to be taken?
>
> --
> Doug Ewell | Thornton, Colorado, USA
> http://www.ewellic.org | @DougEwell ­
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages



-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/