Request to register private-use variant subtags

Doug Ewell doug at
Sun Apr 8 00:07:37 CEST 2012

Gordon P. Hemsley wrote:

>> In fact, once you have started isolating subtags with "Private" from
>> the others, there is really nothing to stop you from declaring script
>> subtags 'Zxxx' and 'Zyyy' and 'Zzzz' exceptional as well.
> And I have, in fact, done just that, along with 'Zinh', as well.

You are really starting to be on your own at this point.

>> You could perform this test against all five types of registered
>> subtag (language, extlang, script, region, variant) by randomly
>> generating a subtag value and checking the Registry, or your
>> database, to ensure that the value isn't already registered, and
>> iterating as necessary. (That's how random, guaranteed-nonexistent
>> filenames are generated.) There's no need to have a predefined value
>> that expressly means "nothing." That isn't what private-use subtags
>> are for anyway.
> The tests are run asynchronously from the generation of the lists of
> names (as discussed further below), so checking the Registry for
> validity is not an option.

Sorry, I should have said "checking your database" instead of "checking 
the Registry."

> In addition, the tests are being run to ensure that the correct name
> is associated with the given language tag. Checking the list for
> validity would create add circular logic to the test and render it
> moot.

string bogusVariant = "";
    bogusVariant = generateRandomVariant();
while (Exists(bogusVariant));

>> But claiming that private-use subtags should not have a "display
>> name" while others should is your concept, not a BCP 47 concept.
> I'm aware of that. This discussion is not supposed to be about how I
> decide what gets a "display name" and what doesn't. This is a
> discussion about whether there should be a variant subtag that has the
> equivalent purpose as a private-use language, region, or script
> subtag. Anything about what that private use actually is is outside
> the scope of this discussion, I think.

Fair enough. I claim that, for the purposes for which BCP 47 envisions 
private-use subtags, it is perfectly reasonable for there to be no such 
thing as a private-use variant; that is what it intends the -x- 
mechanism to be used for. You have a right to define a private agreement 
that says 'qaa' means nothing, 'Qaaa' means nothing, etc., but I don't 
believe this justifies changing anything about BCP 47 or the Registry to 
support this particular testing model.

>> Just check dynamically to make sure the test subtag is still not
>> registered.
> It's not that simple. As I mentioned before, the list that is used is
> not tied directly to the Registry.

Check your database dynamically. Your database is what matters anyway to 
your app, not the Registry, since you've already excluded 'Zxxx' and 
'Zyyy' and others.

> Aside from being self-defeating, checking the Registry for validity
> would require a much more complicated architecture than is currently
> in place.

Sorry, you've reached the wrong audience here. I've spent years trying 
to convince colleagues that asking stakeholders to change their external 
systems to simplify our lives as developers is wrong-headed.

>> Nothing in the Registry, private-use subtags or anything else, is
>> reserved or registered to mean nothing.
> As we've previously established, there is a step in between the
> Registry and what I am displaying. In that intermediate step, I
> translate "private use" to "has no meaning"—something I am completely
> entitled to do.

Since you are working with your own database, derived from the Registry 
but excluding certain subtags, I suppose you could exclude any 
registered variant subtag of the forms 'invalid0' through 'invalid9' and 
use those for your testing. As you said, nobody can flat-out 100% 
guarantee that such subtags will never ever be registered, but it does 
seem pretty remote.

> Well, perhaps your BCP 47 applications did not have a widely
> international and multicultural audience, but accepting the contents
> of the Registry verbatim raises a number of issues, not the least of
> which being political. The prime example in my mind (though there are
> several) is the description of the region subtag 'TW' being listed as
> "Taiwan, Province of China". It is listed this way in the Registry, I
> believe, because that is the value direct from ISO, which is affected
> by governmental politics. However, Mozilla (and most other Internet
> uses, I'm sure) has to answer directly to the people—the developers
> and users—first, and those in Taiwan object to the Description listed
> in the Registry.

By "accept the Registry verbatim," I meant accept its structure and 
semantics, not necessarily the strings used in Description fields. You 
can keep the structure of the Registry intact but display different 
names; French-language UIs would have to do that anyway. (My apps 
transcode apostrophe-like characters in Description fields to improve 
the likelihood of proper display.)

In any event, the Taiwan example is a sticky wicket, as the People's 
Republic of China tends to object if you *don't* say "Taiwan, Province 
of China." It's all about who your market is.

> All of this processing as to be done when converting from the Registry
> to the software, and it would not make much sense to do it on the fly
> every single time the information was needed.

Every place I said "use the Registry," which you are not directly doing, 
please read it as "use your database derived from the Registry."

>> For the reasons I've stated, and speaking partly as a programmer and
>> partly as a BCP 47 Designated Expert, I think it would be a mistake
>> to register a subtag of any type for the purpose "this subtag has no
>> meaning" simply to solve a programming problem.
> It would be a subtag for the purpose of "Private use", of which there
> are several already. My particular private agreement need not be
> formalized in the Registry.

I see no other purpose for a private-use variant subtag other than to 
support this particular processing architecture and testing strategy. 
Sorry, you'll have to try to convince others on this list. You may have 
better luck there.

Doug Ewell | Thornton, Colorado, USA | @DougEwell ­ 

More information about the Ietf-languages mailing list