Micah Dowty wrote:
>
> 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
I think command-line text should not be intl'zed (the os core utilities are in English
as well). This is not anything the end user sees.
>
> 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.
I fully agree.
Concerning the server, since the mechanism is already here for errors, I'd say we
should use it for all other messages (table + numerical msg id). I don't like
converting str to id at compile time, because (although surely nice-to-hack)
programmers don't get aware of the feature. unless they read the makefiles.
Concerning the clients, it's their own responsibilities. It could be useful for them
to access the server's string.
--
Pascal Bauermeister
Head of Software Development
SMARTDATA
PSE-A / EPFL
CH-1015 Lausanne
http://www.smartdata.ch
mailto:[EMAIL PROTECTED]
Phone: +41 (21) 693 84 98
fax: +41 (21) 693 84 91
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
