On the whole, PicoGUI itself doesn't generate much text that the end user sees. The
small amount of text it does use, though, should be internationalized. In addition, a
standard method of internationalizing PicoGUI clients should be defined.
In PicoGUI itself, the following types of text need to be internationalized:
- pgserver errors
- pgserver command-line text
- pgserver theme default strings (i.e. "Ok" and "Cancel")
- cli_c command-line text
- cli_c error dialog box
The current internationalization standard in the Free Software community seems to be
GNU gettext. I have read through the documentation and some of the source code.
Basically, translatable text is marked in programs' source code by enclosing them in a
gettext() call, or optionally the short _() macro. When internationalization is
enabled at compile-time, this expands to a function that searches a dictionary
(basically an associative array on disk) for a translated string using the original
string as a key.
GNU gettext would suit PicoGUI's needs for both server and application
internationalization. Although it takes some measures to increase speed, such as
binary message dictionaries and hash tables, I'm not sure it would be fast enough or
memory efficient enough for use in all embedded applications.
The gettext documentaion describes how the FSF came to the decision to use the
interface that it currently uses. An alternate system that they rejected used a
numeric identifier to look up strings in a table, switching this table for
internationalization. This is basically what pgserver uses internally to manage error
messages.
Maybe there is a way to combine the server internationalization with server error
handling?
I suppose the choices I see for PicoGUI internationalization are:
- Use GNU gettext for everything
- Use some of the gettext development tools, but write a faster runtime
component. Maybe convert the strings to numeric index values at compile
time, looking strings up in a simple array?
- On the server side (and client lib?) combine all messages into the same
table as the errors, and allow loading alternate tables. Let the clients
use some other internationalization method?
It definitely seems like the cleanest solution would be gettext, but it might make
things too slow when internationalization is on.
Does anyone on this list have experience with gettext, or internationalization in
general?
--
To the systems programmer, users and applications serve only to provide a
test load.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
