Dialog labels are localized through the StringSet mechanism as follows:
1. The string ID and English value are defined in the appropriate XAP
(cross-app) or AP (app-specific) strings header file:
abi/src/af/xap/xp/xap_String_Id.h
abi/src/wp/ap/xp/ap_String_Id.h
Note that the predefined macros in each file handle expansion of the full
symbol name for the string ID as needed. For example:
XAP_STRING_ID_DLG_Zoom_PageWidth
vs.
AP_STRING_ID_DLG_Break_Insert
To get the value of one of these string IDs, you need to pass these
fully-specified names -- not the abbreviated version from the header file --
in a pSS->getValue() call to the app's current StringSet object.
For simplicity's sake, we sometimes wrap the calls in macros to make the
code more readable. For example, see the _DS and _DSX macros in the
following file:
abi/src/wp/ap/win/ap_Win32Dialog_Break.cpp
2. Localizations for these strings are provided by adding a translation for
each new ID to the relevant Strings file in the following directory:
abi/user/wp/strings/*.strings
Our binary installers copy updated versions of these Strings files into the
appropriate locations, but developers may need to do a top-level make
canonical to get the same effect.
Note that the StringSet mechanism "knows" to fall back to English for string
IDs which don't yet have a localized equivalent. As an aid to translators,
a debug message is generated at runtime for each untranslated string ID.
Alternatively, you can always pass a -dumpstrings command-line argument to
generate a current EnUS.strings file.
3. Finally, since the widths of localized strings may vary from language to
language, it's important to not pack dialogs too tightly. Even so,
translators may later need to widen the dialog layouts to make sure that
everything fits. Unfortunately, this is still a platform-specific task
which involves manually tweaking size information in the dialog layouts.
On GTK, dialog layouts, dimensions, and packing order are specified via
inline code:
abi/src/wp/ap/unix/ap_UnixDialog_Break.cpp
On Windows, all dialog widget sizes are explicitly specified in the
corresponding resource file:
abi/src/wp/ap/win/ap_Win32Res_DlgBreak.rc2
On BeOS, the dialogs are defined in binary resources which get "rehydrated"
at runtime:
abi/src/wp/main/beos/break.rsrc
In each case, the tools used may vary, but the same iterative process is
used -- load up the offending strings file, look at the crunched dialog,
widen the dialog template, rebuild, and see whether you got it wide enough.
When done, submit the relevant patches.
Paul