Now that we've got everything switched over to the new AbiSource machines --
thanks, Shaw! -- it's time to get rolling again on POWs. For this week's
project, I've chosen a larger task which is likely to take work from several
folks.
the goal
--------
Make translated dialogs "fit" on all platforms without getting "too big".
Avoid solutions which require each new translator to widen arbitrary fields
to make their stuff fit, too. (With more dialogs and more translations
being added all the time, we need a practical solution which scales.)
how to help
-----------
Send a ZAP or SHAZAM note to the abiword-dev list claiming one of the steps
listed at the bottom of this note. This is a team effort, but no single
step should be that hard. Total volunteers needed would be:
step 1 -- one
step 2 -- one per translation
step 3 -- one per platform
step 4 -- one per platform
In addition, we'll also need one person who's willing to own the entire POW.
Their job will be to coordinate all these activities, and make sure
everything gets checked in.
background
----------
Our user interface has currently been translated to 10 languages (besides
English), namely:
Catalan
Danish
Dutch
Finnish
French
German
Italian
Norwegian
Portugese
Spanish
The dialogs were originally laid out on each platform to look good in
English with some extra space, in the hope that strings wouldn't get *too*
much longer in other languages.
For example, the English word "OK" appears on almost every dialog, but the
button size was made a lot wider than that in each dialog because the
equivalent words in some other languages are more than 2 characters long.
Still, not all translated dialogs "fit" -- some translated strings get
truncated, which is Not Good.
the tradeoff
------------
This is a tricky problem for UI designers and translators, and it needs to
be tackled from both ends.
On one end, each translator needs to consider both the *length* and the
*meaning* of the words they use in their translations. Fortunately, for
many languages these problems have been addressed repeatedly for many
programs. Often, there's a "standard" translation for various computer
terms which is no longer than it has to be.
On the other end, somebody needs to go in and gradually widen specific
fields in each dialog to make everything fit for all languages. Preferably
this is someone with an "eye" for what looks too crowded vs. too airy.
The tradeoff here is obvious:
- Translators' lives are easier if length is no obstacle.
- UI designers' lives are easier if all strings are short.
worse, this problem is platform-specific
----------------------------------------
Unlike most other portions of the UI, dialogs are the one place where we
haven't invested the months of effort it would take to make dialog resources
totally XP. They get laid out, by hand, once for each platform. See the
abi/shots directory in the source drop for pictures.
On Windows and BeOS, all dialogs are laid out with fixed sizes in
platform-specific resource files.
The GTK designers have attempted to solve this problem via a
constraint-based layout system which allows widgets to resize themselves
based on their contents. As recent discussions on this list point out, this
works better in theory than in practice. Perhaps for this reason, many of
the GTK dialogs are laid out (in code) with fixed sizes, too.
steps towards a solution
------------------------
Fixing this problem will require a team effort in four steps, each of which
could be tackled by someone else.
1. Code analysis. It'd be nice to have a quick command-line utility which
compares all the strings files, so we can see which translations are
longest. For example, here's some sample output:
<pre>
DLG_OK
------
EnUS: DLG_OK="OK"
CaES: DLG_OK="D'acord"
DaDK: DLG_OK="OK"
DeDE: DLG_OK="OK"
DuNL: DLG_OK="OK"
EsES: DLG_OK="Aceptar"
FiFI: DLG_OK="OK"
FrFR: DLG_OK="OK"
ItIT: DLG_OK="OK"
NoNO: DLG_OK="OK"
PtPT: DLG_OK="Aceitar"
DLG_Cancel
----------
EnUS: DLG_Cancel="Cancel"
CaES: DLG_Cancel="Cancel�la"
DaDK: DLG_Cancel="Annull�r"
DeDE: DLG_Cancel="Abbrechen"
DuNL: DLG_Cancel="Afbreken"
EsES: DLG_Cancel="Cancelar"
FiFI: DLG_Cancel="Peruuta"
FrFR: DLG_Cancel="Annuler"
ItIT: DLG_Cancel="Annulla"
NoNO: DLG_Cancel="Avbryt"
PtPT: DLG_Cancel="Cancelar"
DLG_FR_ReplaceWithLabel
-----------------------
EnUS: DLG_FR_ReplaceWithLabel="Re&place with:"
CaES: DLG_FR_ReplaceWithLabel="Reempl&a�a per:"
DaDK: DLG_FR_ReplaceWithLabel="Erstat med:"
DeDE: DLG_FR_ReplaceWithLabel="Ersetzen durch:"
DuNL: DLG_FR_ReplaceWithLabel="Vervang door:"
EsES: DLG_FR_ReplaceWithLabel="Reempl&azar por:"
FiFI: DLG_FR_ReplaceWithLabel="Korvaava:"
FrFR: DLG_FR_ReplaceWithLabel="Rempl&acer par:"
ItIT: DLG_FR_ReplaceWithLabel="Sost&ituisci con:"
NoNO: DLG_FR_ReplaceWithLabel="Erstatt med:"
PtPT: DLG_FR_ReplaceWithLabel="Sub&stituir por:"
DLG_Para_LabelLineSpacing
-------------------------
EnUS: DLG_Para_LabelLineSpacing="Li&ne spacing:"
CaES: (missing)
DaDK: (missing)
DeDE: (missing)
DuNL: (missing)
EsES: (missing)
FiFI: DLG_Para_LabelLineSpacing="&Riviväli:"
FrFR: (missing)
ItIT: (missing)
NoNO: (missing)
PtPT: (missing)
</pre>
As this selected sample shows, in most cases there seems to be a consensus
about what's a "reasonable" length for each string.
For extra credit, it might also be interesting to crunch that same info in
other ways, letting each translator know which of their strings are longest,
which still need to be translated, which don't have & accelerators, etc.
Or, it might be fun to use that info to automatically create a file called
Longest.strings which can be used to check dialog layouts. :-)
2. See if the translations can be trimmed. Given the output from step 1,
each translator will know when their language has an especially long
translation for any particular string. Those are the ones which will have
the hardest time fitting, and thus are prime candidates for trimming.
3. See what doesn't fit. Once we've determined the maximum length needed
for each widget, we'll need three volunteers -- one for each platform -- to
go through and figure out which items will need to be lengthened. (Be sure
to mention what display depth, pixel resolution, etc. you're testing on,
since this can affect how your platform sizes things.)
4. Widen those fields. Given the list from step 3, someone with a nice eye
for graphic design standards on each platform should go through all the
dialog resources on that platform and judiciously widen things just enough.
That oughta do it!
Paul
PS: For more background on the whole POW / ZAP / SHAZAM concept, see the
following introduction:
http://www.abisource.com/mailinglists/abiword-dev/99/September/0097.html
