Re: [XBoard-devel] Re: Internationalization question

[Tim Mann]

It's easy to decide between these two options.  It has to be (1), not
(2), because xboard and WinBoard share a lot of code, some of which
contains strings that must be internationalized.  For example, backend.c
contains such strings.  We're not going to split that code into two
versions, one for xboard that uses gettext and one for WinBoard that
gets its strings from a Windows resource file.

It would be nice if there were also options that allowed us to use
gettext uniformly for everything: (3) Use gettext on the .rc file too,
or (4) Move all strings out of the rc file into a C file and use gettext
on that.  Perhaps (3) is not possible; I don't know, not having found
time to educate myself about gettext and what it can do.  (4) should be
possible in principle, but would be a lot of effort and would make it
difficult if not impossible to use a dialog editor on the .rc file.

Anyway, I'm content for us to go with (1).

On Wed, 18 Feb 2004 22:41:25 +0200, "A. Alper ATICI" <address@hidden> wrote:
> Hi Tim,
> 
> On Tue, Feb 17, 2004 at 11:41:24PM -0800, Tim Mann wrote:
> [...]
> > 
> > I don't think you can do that in a week using WinBoard + GNU Chess,
> > because (as Alper just explained on the mailing list), the
> > internationalization support for WinBoard is not complete yet.  No one
> > seems to know the right way to internationalize the strings that are in
> > winboard.rc, and those make up a lot of the UI -- all the menu text and 
> > 
> 
> Windows resource i18n is not a mystery, that's a known topic. 
> What I emphasize on is the vagueness of achieving it using gettext. If 
> everybody agrees 
> on that, there seems to be two options for Winboard i18n:
> 
> 1. Use gettext for c-strings; add localized resources for dialog boxes, menus 
> and 
> resource strings.
> 
> 2. Transform every c-string into resource strings, add localized resources as 
> above.
> 
> 
> The first option segregates i18n effort. Translators will have to deal with 
> both gettext 
> po files and RC files. But it brings less burden on the developer.
> 
> The second option drops gettext, makes everything RC-based. This means less 
> burden on
> the translator, however it increases the burden on the developer. Using 
> c-string
> literals will simply be forbidden from there on, every string has to be a 
> resource.
> 
> 
> If a decision is made, then things will be clear for me.
> 
> regards,
> 
> -- 
> A. Alper ATICI
> PGP key: http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0xB824F550
> fpr(S) = DFA9 6619 70C7 400C 1DA8  7BFB 2C56 F3AF B824 F550 
> fpr(E) = D314 04FF 7A8C EBE0 68AE  D692 A1B5 A14B C0CD 4D4A
> 
> 


-- 
Tim Mann  address@hidden  http://tim-mann.org/