Sounds good. How about the client library? The only text it has (besides the command
line options) is the message for the PicoGUI error dialog. For that, we could:
- Leave it alone. The errors are cryptic enough that it won't matter what language the
dialog box is in ;-)
- Somehow get that text from the server along with the error message itself
- Define it as a global theme string (like the "Ok" and "Cancel" text used by
dialogs) so it can be internationalized along with the rest of the server, or even
replaced using a theme. The client lib could retrieve the string
when it needs to display an error dialog.
I like that last option, storing it as a theme string. Any objections?
On Wed, 27 June 2001, Pascal Bauermeister wrote:
>
> 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
--
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
