Adding RAINBOW FLAG to Unicode

[Ken Whistler]

On 7/2/2015 2:01 AM, Philippe Verdy wrote:
>
> The frozen status of Antarctica ...

... will be addressed separately by global warming. But be that as it may...

>
> In really there's still no standard way to encode flags unambiguously 
> and in a stable way. We'd like to have FOTW (Flags of the World) 
> contributors to propose their own scheme. But it will not be 
> compatible with the current RIS solution or the proposed extension. If 
> ever such standard emerges, it will require encoding a new set of 
> characters.

The UTC is neither responsible for nor interested in a "standard way
to encode flags unambiguously". I suspect one of the reasons this
discussion is tending to derail into political topics and too much detail
about particular flags and their stability and the stability of geopolitical
entities they represent and yadda yadda, is that people seem ineluctably
drawn to the misapprehension that this is all about standard encoding
of flags.

It is not.

Rather, it is about a standard way to represent recognizable and 
interchangeable
emoji (colorful little pictographs) of flags, using defined sequences of
Unicode characters.

The existing mechanism using regional indicator symbol (RIS) pairs was
originally aimed at solving the following problems:

1. Enabling the reliable interchange of the legacy 10 flag emoji from 
Japanese
carrier sets.

2. Enabling the completion of the encoding of emoji to cover the rest
of the Japanese carrier sets without all progress dragging to a
complete halt as national bodies in SC2 would argue interminably over
a "standard way to encode flags unambiguously" in an ISO standard.

3. Dealing with the inevitable hue and cry: "China and Japan and the US 
got their flag!
Why can't I get my country's flag??!"

And it appears that the RIS mechanism succeeded spectacularly well in
addressing all of those design goals.

In the middle of last year, for example, there was a major media and
internet campaign to "encode the flag of India". Well, the RIS mechanism
handled the real issue there just fine -- when the new phones started
coming out with support for display and interchange of emoji for flags
using the RIS sequences, there was the emoji for the flag of India for
everybody to use. Problem solved.

And the problem which was solved was /not /the determination that
the <1F1EE, 1F1F3> RIS sequence "IN" meant /precisely /the current
national flag of India, the saffron, white and green tricolor with the
Ashoka Chakra, and *not* any other flag of India (the flag of the
Indian army, the flag of the Mughal Empire, the flag of British
India, etc.). The RIS sequence "IN" was just mapped to the colorful
little emoji glyph for the Indian flag that everybody wanted to interchange.

The Unicode Standard is not a vexillology standard -- nor will it ever be.
It is a standard for the encoding and interchange of characters.

The *character* problem we are faced with here is that people want
to use and interchange colorful little emoji pictographs of various
flags in text streams. The RIS mechanism addresses a significant
part of that problem, but is not extensible to cover the full scope of the
demand.

And what is the scope of the additional demand?

1. The first part can be summed up as: *the flag of Scotland problem*.

In other words, there are a number of high visibility, high demand,
widely recognized /regional/ flags that would be interchanged as just
more emoji pictographs, if a mechanism for that were available.

People who want to use an emoji for the flag of Scotland just as
easily as someone can use an emoji for the flag of Great Britain
are not going to accept an argument that says, "Well, we can't do
that on your phones because there is no 3166-1 country code registered, so
we can't map a Scotland flag emoji glyph to a RIS pair."

Hence the PRI #299 proposal: for an extension mechanism that would
address the flag of Scotland problem in a generic and reasonably
stable way.

2. The second part can be summed up as: *the rainbow flag problem*.

In other words, there are a number of high visibility, high demand,
widely recognized /non-governmental/ flags that would be interchanged
as just more emoji pictographs, if a mechanism for that were available.

 From the public's point of view, this is another no brainer: if the
flag of Japan and the flag of Scotland, why not the rainbow flag??!
They aren't interested in the limitations of the underlying representation
mechanisms, nor should they be, IMO.

The problem the UTC faces here is that there are a number of
reasonable and popular candidates, which the rainbow flag amply
exemplifies, for more colorful little emoji pictographs for flags that
people would like to interchange -- but there is no obvious and
extensible way to do so reliably in terms of sequences of Unicode
characters in a plain text stream. The PRI #299 proposal does not
extend into this realm, for many of the reasons pointed
out by Doug Ewell.

There are a number of potential approaches to address the rainbow
flag problem. For example:

a. use private-use characters
b. pursue one-by-one encoding of each newly desired flag pictograph as a 
symbol
c. extend the unicode_region_subtag and unicode_subdivision_subtag
scheme in CLDR to add some new subtag addressing a separate,
non-geopolitical hierarchy
d. create a separate extension using TAG characters but with a
syntax not dependent on CLDR subtag definitions
e. create a registry of flag entities suitable for representation as
emoji, together with a "c" or "d" style syntax
f. something else?
g. do nothing (and perhaps hope that stickers will solve the problem)

If we are to make any progress here in addressing the actual scope
of "the rainbow flag problem", I suggest we focus on the details and
pros and cons of suggestions like those of a through g above, rather than
pursuing more discussion recapitulating the history of the borders of 
Tibet --
which truly are out of scope here.

--Ken


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150702/e1072797/attachment.html>