[sldev] Translations

[Alissa Sabre]

> > - Translators should not touch the XML files at all. One string can be
> > used at hundreds of places but will only be translated once.
> 
>    What if the size of an UI element has to be adjusted to fit the  
> translated string? This is not too uncommon.

I have several comments.

On "One string can be used at hundreds of places":

Zitat wrote "can", and it is true, but the decision to use a string is
not easy in general, and is not recommended for developpers to assume
one particular English word always translates to a same word in
another language.

For example, an English word "light" sometimes refers to a source of
brightness and sometimes refers to less weighted.  Not all language
use a same word for both.  In Japanese, there are two separate words
for them, and it had been a famous bug of Japanese translation of
viewer UI that the word "light" used as the former meaning was
translated to a Japanese word of the latter meaning.  (It is fixed in
1.18.0, BTW.)  Interestingly, the word "Light" alone is used as a
label of a field of viewer dialog box already.  The translator can't
choose a correct word unless he/she understand the context (i.e.,
appering which dialog box, what actually does it refer to, etc.)

It is good providing a mechanism that allows translator to reuse same
translation multiple times, but the mechanism must be used as an
option.  (That's the primary reason I hate posix gettext()...)

So, I hope the soon-to-be-available viewer skinning mechanism doesn't
fall into this pit.

On "What if the size of an UI element has to be adjusted":

Good point, Boroondas.  We have three practices in the industry today
to solve this issue.

(1) Design dialog boxes to make enough space for the longest possible
    translation texts.  For example, when you have a 6 letter label in
    English, just use, say, 30 letter space for the label, unless you
    know exactly what words are used for the label in 38 major
    languages. :-)

    This approach is used in many simple projects, and its drawback
    is, of course, very sparce dialog box design.

(2) Make dialog box components (controls) to adjust their sizes based
    on the content texts.  This approach is used in Java
    (Both Swing and SWT do this).

    The drawback is the difficult dialog box design.  If you are
    designing some complex dialog box with a lot of controls, you need
    to express some _constraints_ that describe how to adjust the
    overall layout when the size of the controls change.

(3) Let translators adjust dialog box design.  This is the approach
    Boroondas assumed.  Also, Microsoft development tools (e.g. Visual
    Studio) take this approach.

    Although this gives the best result when done properly, it
    requires a lot of resources (man-power) to complete.  The problem
    is that most of good translators are not good at visual design, so
    the translation should be passed to designers for redesign.
    Another drawback is the synchronization with the new versions of
    code.

So, what should our skinning mechanism be?  I'm not sure exactly, but
I'm happy discussing it on this list or on wiki.

    Alissa Sabre
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/