Re: Icon Love (long-ish)

[Calum Benson <calum benson sun com>]

I promised to post the responses of the people I asked around Sun about
localizing icons.  So, here they are.

Executive summary: It's better not to have to localize icons, because
it's difficult and time-consuming (and expensive, if you're paying
someone to do it), and some users won't like it.  But for some icons
there is just no good alternative, so make sure the system supports
localized icons for those situations.

Cheeri,
Calum.

---

Localizing icons is work (especially since it's typically hard to find a
visual designer from the culture in question, so even if you localize,
you have someone who may not understand the nuances).  Sun tries to
avoid localizing whenever possible.  The only counter example I can
recall is Hot Java Views, and that was because there was text on  the
icon, and they had to localize the text.

What we have typically done is to put icons in a locale specific
directory (with appropriate fallback to get them from the C locale if
the icons aren't the locale directory) so that particular icons could be
localized if necessary, but then try to create culturally neutral icons
if at all possible.  Some of the more challenging issues that I recall
encountering are:

   - icons that need text.  The Hot Java Views was a special case (they
didn't have tooltips, as I recall), but what do you do with a button
that means "bold the text"?  

   - icons that need people in them.  Human figures are always tricky.
How do you differentiate reply from reply to all? 
   
I have encountered situations where people from other countries felt
they were getting a "second class" product because it didn't have the
same icons as the US version.  And if you have people moving from one
version to another, having to learn new icons is an added burden for
them.   

BTW, locale isn't enough.  Locale is a language concept, while icons are
a cultural concept.  I'm sure I could design an icon set that would make
no sense in the UK (I learned this the hard way when I worked on a
project where a UK person designed a status icon that was a portcullis
-- how many US people even know what a portcullis is, 
much less would be able to associate it with a dropped network
connection?), and we at least pretend that those are both the same
locale.

---

I have seen issues with in previous jobs with the occasional icon that
simply must be redone for other cultures.  Usually good icon design can
avoid it (for example, to solve the problem that mailboxes look
completely different in different places, draw the envelope itself with
arrows on it rather than a mailbox), but there are occasional cases
where it's virtually impossible to come up with anything international.

The example which comes to mind is interestingly a U.S. vs. U.K. one,
underscoring Robin's point that it is not language which is the
differentiation (although admittedly the two languages aren't exactly
the same either!).  For an expense reporting application I was helping
design, we needed an icon to represent Taxi.  We couldn't come up with
any symbol which was common between the two countries. The cars look
entirely different, the meters look different, the currency symbol is
different, etc.).  So the graphic designer made a second icon set for
the U.K. with everything the same except that one icon, which was a
black PT-Cruizer-like car for the U.K., and a yellow Checker-cab-like
car for the U.S.

Bottom line is that good icon design can usually avoid the problem, but
-- even without text in your icons -- you may still have exceptions
which simply need a small amount of localization (or as they say in the
U.K., localisation).

Personally, I think the N, I, S problem is a compelling one.  I would be
curious why my bold icon was a N if the situation was reversed (or
perhaps feel like a second class user if I understood why).  So this
might be a good case for making a localized icon (a pretty easy one to
draw at that).  On the other hand, the designer should think first about
whether there are other solutions to reduce the number of variations
needed, if not get down to one.  For example, what if the icons were a
few greeked-out letters, which were bold, italic, and underlined
respectively, at least for places where the standard B, I, 
and U don't work?

---

What is ironic about the previous example is that the word TAXI would've
worked perfectly in both "languages". Further, it is just about the only
word that works in all languages (that I can think of), at least those
using the western alphabet. So it might be just about the only text you
could think of putting on an icon/button. I'm sure someone will find a
language that doesn't call it a taxi, but I would also guess that
business travelers using the application know what the letters/symbols
t-a-x-i are referring to.

So an even more bottom line is that you may need to consider text in
some very rare cases where it might work. Of course, you may not want
text for other reasons (coherence with other buttons, etc.).

> On the other hand, the designer should think first
> about whether there are other solutions to reduce the number of
> variations needed, if not get down to one.  For example, what if the
> icons were a few greeked-out letters, which were bold, italic, and
> underlined respectively, at least for places where the standard B, I,
> and U don't work?

I had an idea for solving this particular problem in engineering: since
the icon on the button is supposed to represent text with some
formatting, why not use a text label instead. That way they would just
be another 3 text strings to localize, and the translators can use the
letters that are most appropriate to that language. Maybe some cultures
don't have many localized applications and are actually used to seeing
B, I, and U on their buttons. Just be sure to have a clear explanation
of these strings in the source file containing the strings to be
localized.

---

I vote one set of icons for the world.  Tigert gave most of the reasons
why.

It's funny he mentions the "A->Z" sort icon - I just flagged that on the
Forte For Java product.  While "A" might be universally understood as
representing a character glyph (and I emphasize the word "might"), I
doubt "A->Z" is remotely universal.

Let's face it, it is very difficult to come up with a universal icon
that people from all over the world can simply look at and understand
what it represents.  What the icons do is jog the memory.  A tool tip or
help message initially provides a clue, and once a user has used the
icon a couple of times, they then associate it with the action.  So,
maybe a simple graduated down arrow would be sufficient for "ascending
sort".

It would be great for some standards body to come up with a standard set
of icons for some basic operations :-)

---

- Usually icons do not and should not have text on them. They ought to
be a pictorial representation of functionality available in the
application. Generally with icons the same functionality is also
accessible through menus elsewhere in the application. Text in icons is
bad policy for localisable applications as it increases the time and
expense spent on that localisation.

- Sometimes the localisation of icons is necessary (even those without
text) because the visual representaion of the functionality is not
sufficiently cross cultural. If a developer suspects that this is the
case for a specific icon she ought to i18n it. If
uncertain about suitability in general then all icons ought to be
i18n'ed within the application. This is the safest but also the most
time consuming approach.

---

Personally, I like localised labels for icons that don't change. When I
switch between French and English-language versions of a well-known word
processing system, I find it a useful reminder to see the icon labels
(or mouse-over text) in the appropriate language, but I don't expect the
icons to change because the functionality doesn't change.

---

Making sure anything that's culturally offensive is switched out where
appropriate is an absolute must.

For a completely fictitious example, an underlined U might be offensive
to French Canadians, so when you do *just* the French Canadian version,
there is where you would spend the extra effort to change to all "A"s.

---

Looking to the future we should push GNOME to adopt .svg images as the
standard image format as this is plain XML and has strong l10n/i18n
features in it. For example text is usually a string in the file. Also
fonts can be embedded in it if necessary as well as all translations
into a single file. The .svg renderer selects the translation based on 
the system settings. Also it looks better on screen.

In the case of the 'B' and 'i' type icons I would suggest using a simple
label with formatting on the button. Easy to l10n then. Yes it mightn't
look as nice but it works, and it will work now. I'm not sure about the
idea of providing "icon_de.png"-type images as this will put the onus on
us to work with the images.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems