Standardizing icon names: flags
jub at sun.com
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 . If you want to do it nevertheless it
is hard to get right generically for an international audience . 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
> 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
,) 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.
 Jukka Korpela: Flag as a symbol of language - stupidity or insult?
 Flags representing languages?
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer joerg.barfurth at sun.com
OpenOffice.org Configuration http://util.openoffice.org
More information about the xdg