Re: [dcplusplus-devel] i18n

[Jacek S. <arn...@gm...>]

David Grundberg wrote:
> Well, yes, but...
> 
> After spending a day trying to build 0.17 with no success, I eventually 
> just used a precompiled gettext-0.16. I cheated and removed the 
That's fine. If that is all that it takes, I'll remove the flag for now until 0.17 becomes widely
available...where did you find it? (So that I can include a link...)

> package-name flag from the SConstruct pot builder. Only to find out 
> there is something wrong with how gettext is run by scons, and I get no 
> dcpp/po/dcpp.pot file and a very small win32/po/dcpp-win32.pot file. 
> Confusion. Running the same command by hand gets the job done however. 
> Someday I'll just use a Linux box instead of this Windows deal.
There's nothing wrong - there are just very few strings that are actually gettext-translatable right
now. If there are no strings, it doesn't create any pot (as in the dcpp-case).

> I'm curious, why is both _ and _T extracted? Isn't _T the unicode string 
> marker for win32 unicode/ansi builds? What I expected was that _ was 
> used for translatable (unicode/ansi) strings, while _T is for hardcode 
> (unicode/ansi) strings. But perhaps that's just a wxWidgets thing. We 
> need to make a difference between the two anyhow.
Actually, it's T_...the way I set it up, gettext returns utf-8 (assuming that the translations are
in utf-8). If you look at T_, you'll see that it'll convert that into a win32 wide string usable
from the gui (otherwise you'd have to do "Text::toT(_("blah"))" every single time).

> On number 3:
> 
> Yes, reading the pot-files and the translated dc++-xml file would be 
> needed. But how are the strings going to be represented in the pot-file? 
> Like the actual literal string I hope? ("Add To Favorites" instead of 
> ADD_TO_FAVORITES or AddToFavorites)
Yes.

> Using the literals, StringDefs.h would have to be input to the 
> conversion too, in order to translate from the enum value (which is read 
> from the xml) to the untranslated string (which can be looked up in the 
> pot). We'd have to modify the makedefs script to output gettext_noop() 
> around the literals in StringDefs.cpp too.
Actually, StringDefs should go away. That's what the conversion is about - to take the actual string
from StringDefs.h, and replace all STRING(ENUM) instances in the source code with it. While doing
this, any strings that take parameters should be converted to boost syntax.. Also, all STRING(XXX) +
Util::toString(yyy) should be converted to "xxx: %1%" so that the parameter can be moved inside the
string...

In the end, we should only have _("xxx") and T_("xxx"), no STRING, CSTRING etc...Possibly, we'll add
a few more _-type macros (return xstring vs c_str())...noop and plural handling spring to mind as
candidates for new macros as well...

Another candidate would be a macro that returns a boost::format object at once ("#define F_(String)
boost::format(String)") to make it less intrusive...

> Also, xgettext is instructed to read the source files as UTF-8, but 
> makedefs.py seems to think StringDefs.h is in CP1252. What encoding are 
> the source files supposed to have?
UTF-8. Although I thought all files were ascii-clean (by using \xxx escapes to produce the correct
utf-8)?

> 
> I'll just end this mail here while it's not a book. Sorry for this 
> gigantic post :)
Well, it's better if we agree now to avoid unnecessary work later on =)

/J