Micah Dowty wrote:
>
> 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?
I like it too. If I remember well, we can have the default theme define the text, and,
if we omit the text in overriding themes, it will appear as defined in the default
theme ?
Pascal
>
> 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
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
