Standardizing icon names: flags

Joerg Barfurth jub at
Thu Nov 11 12:16:23 EET 2004


Frans Englich wrote:

> There is no hesitation for that flags potentially causes trouble, as countless 
> of examples and prior discussions shows. The Icon Theme Specification can 
> hence not contain anything which poses those problems on anyone who wants to 
> conform to the specification. For example, it can under no circumstances 
> require distributors to ship actual flags.

> However, while flags clearly are complicated in some situations, they are also 
> in some case of interest -- some users wants flags, others don't. In other 
> words, the flag-dilemma is a subjective and conventional matter, with no 
> absolute answers. The specification may not force a definite answer, whether 
> flags should be used or not, on anyone, but leave that to the implementors, 
> such that flexibility is kept, and the policy decision is where it belongs: 
> at the user, or whatever service provider acting on his/her behalf.

The real question IMHO is for what purpose flags are of interest.

Flags (at least those we are talking about here) represent countries. 
They should not be used for anything else. If there is real need to 
represent countries, then you could specify icon names for that purpose. 
e.g. country-xx, where xx is the two-letter code from ISO3166. 
Personally I haven't seen flags used for that purpose in software often 
enough to justify standardizing them.

In actual practice flags are most often used to denote languages. 
Generally that is a bad idea [1]. If you want to do it nevertheless it 
is hard to get right generically for an international audience [2]. If 
you think you need to standardize identifiers for icons to represent 
languages, then you should use an name like language-xxx, where xx[x] is 
the two- or three letter language code according to ISO639 or the 
extended form language-xxx-yy, where xxx[-yy] is the language/locale 
identifier according to RFC3066 that caters for sublanguages with 
variations. But as using flags here is really not the right thing to do 
and visual representations of languages that are not country flags are 
hard to find, I doubt that this should be standardized.

But your proposal now sounds as if you want to detach flags from their 
political implications and not prescribe a binding to a language to 
avoid these issues. The only thing that remains is to standardize on the 
pictures. Then you might go for flag-xxxxx names, but it is not at all 
easy to find a reasonable standard here. Reasonable names might be 
flag-union-jack or flag-stars-and-stripes-50, but most flags don't have 
such names. Using country codes is not really an option, as not all 
regions that have flags are countries (what is the country code for 
Scotland or Bavaria?), countries may change their flag and some flags 
are even used used for multiple region (e.g. German Schleswig-Holstein 
has the same flag as the Netherlands). Moreover this would leave little 
to standardize - an icon thema could not really contain a different (but 
non-empty) picture to represent a certain flag. And in the end I can't 
see what flags by this categorization would be good for.

> The reason to why I want icon names for flags standardized in the 
> specification, is to make it easier for /everyone/ to have the flags exactly 
> the way they want it, without restraining others. The principle is very 
> simple: when the policy decision is done in the icon theme, it's only a 
> matter of selecting an icon theme of ones taste, to get whatever flags -- or 
> none -- of interest. For example, RedHat, who doesn't want to ship flags, 
> will simply use an icon theme with blank icons, and they have solved the flag 
> issue for all of their applications.

Again: why and for what would users or application authors want flags in 
the first place. Also generally if an application uses flag icons, it 
does so to provide a visual way to represent and distinguish the 
entities denoted by the flag (be it countries or languages). If 
designers of icon themes are to be expected to provide useless, 
indistinguishable, blank icons for this entire category, because - as 
discussed in this thread as nauseam - there is no politically correct 
way to provide proper icons, then this set of standardized names becomes 
all but useless to product designers. If I can't rely on the fact that 
my use of flag-de and flag-gb allow my users to distinguish between 
something German and something British, then I can't use them for any 
real purpose.

> The alternative is to not have flag-names in the specification. By doing that, 
> the highly subjective and touchy decision of using flags or not, have been 
> pushed back on individual projects and applications, instead of being coded 
> centrally in the icon theme. 

Great! Using flags is wrong in most cases, so let's push it back to 
those individuals who insist on repeating the mistakes of the past.

> In concrete terms, would the names be "flag-xx" where "xx" is a two-letter 
> code for a country, as per ISO 639.

As mentioned by others (and by me elsewhere) ISO 639 represents 
languages (and some languages have only three-letter codes, whereas 
others have both two- and three-letter codes). Country codes are 
standardized in ISO 3166.  Both these standards have the additional 
problem that they change as political circumstances change, so they are 
not a really stable target.

The fact that you confused the two is another indication that the 
purpose of this suggested standardization is not really clear.

> To make it clear: Standardizing the names does not mean everyone have to 
> design flags and ship them, it only requires that images are 
> there(transparent, blank), or noon at all, if it is known what applications 
> will need. That's the point with the icon theme; the design/implementation is 
> in the theme.

But any decent implementation must support the semantics of the 
specification. Allowing blanks to be used for a set of icons whose 
purpose is to visually distinguish a set of entities is uttely broken.

> Alexander(RedHat, Gnome), writes in the thread:
> "The only way we would ship this is with blank files for all flag-xx. What use 
> is standardizing them then?"

> First of all, there are others except RedHat/Gnome that will use the 
> specification, so while it won't gain Redhat/Gnome on that particular point, 
> it do gain others. 

You still don't tell us what they gain. Standardization is for 
interoperability. Here it is known that using this standard won't 
interoperate with a significant fraction of the free desktop world.

> Second, one advantage, even for those who won't ship 
> "real" flags, is that their work have become simpler; instead of forking 
> existing packages or persuading maintainers to follow their opinions in the 
> flag issue, they simply use their own icon theme. Less friction, because the 
> policy decision is in the theme.

Assuming that package uses flag icons for a real purpose, you have made 
it easy for those who don't ship flags to break the packed in their 
product. They will still have to fork (or work with  upstream to fix) in 
order to restore the lost functionality, so actually very little is gained.

> Another comment Alexander did, was that he thought mapping country codes to 
> flag symbols is tricky -- but that task is only for those who choose to ship 
> flags, it's not a dilemma the specification would create. For example, it's 
> not a problem for RedHat since they won't ship flags.
Please state clearly whether you want flags labeled by country or by 

If you opt for languages, then the mapping becomes a real problem (see 
[1],[2]) for anyone who wants to implement an icon set to match the 
specification. You can't be serious that this is no problem because it 
'only' affects those that want to implement the spec seriously, rather 
than stubbing it out.

If you go for countries, then the problem affects any package author 
who wants to use flags for languages (and so far this appears to be the 
only use case). And it affects them worse than now, because they have to 
explicitly code against a country identifier rather than having their 
private icon theme for representing languages.

> Think twice, and think about everyone the spec will affect, and object if that 
> is what you think. Make sure you have a good reason. 
> Whatever people prefer, will be what the second draft contains.

I seriously prefer to leave flags out.

Ciao, Joerg

[1] Jukka Korpela: Flag as a symbol of language - stupidity or insult?

[2] Flags representing languages?

Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at Configuration

More information about the xdg mailing list