xboard-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] Re: Internationalization question


From: A. Alper ATICI
Subject: Re: [XBoard-devel] Re: Internationalization question
Date: Thu, 19 Feb 2004 17:09:31 +0200
User-agent: Mutt/1.5.4i

Hi Tim,

On Wed, Feb 18, 2004 at 10:38:39PM -0800, Tim Mann wrote:
> 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.
>

I admit I overlooked the strings in shared code while making the second
statement. Thanks for reminding me, discussion has many uses...
 
> 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,

this would be ideal, but not trivial because RC is not itself an executable
code, so gettext() calls cannot be embedded. I think strings can be marked
with N_(). RC files accept #define directives, so N_() should not upset the
resource compiler later on (but I don't know how resource editor will behave). 
But then, gettext() will have to be called for every string in menus and
dialog boxes before window creation.  I'm not sure how ugly that will be.
OTOH, I've not googled anything about this subject on the net so far, maybe
it's time before pondering further.

> 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.
> 

If you're willing to give up visual RC editing, then things will probably be 
better for gettext, but the code may turn into a hideous hack I guess. 
It's an idea anyway, maybe a hybrid approach will become a solution.

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

Since it's certain that gettext will be included, I can give (3) a try 
first, is that OK?

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

Attachment: pgpTYuXsc7uLV.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]