Re: [dcplusplus-devel] i18n

[David G. <c0...@cs...>]

Jacek Sieka skrev:
> 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...)

Goto:
http://sourceforge.net/project/showfiles.php?group_id=2435

Download:
gettext-0.16.1-1-bin.tar.bz2
gettext-0.16.1-1-dll.tar.bz2
libiconv-1.11-1-dll.tar

Untar with 7-zip. Add the path of the bin folder to the environment 
variable PATH. Done.

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

Okay! I see!

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

Yeah, my bad. Apparantly I've just been focusing on problems, inventing 
new ones to fill the quota. Thanks for setting it straight.

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

Okay, I take this is what you really want help with :D

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

I'll keep this in mind.

> UTF-8. Although I thought all files were ascii-clean (by using \xxx escapes to produce the correct
> utf-8)?

Yes, I just pointed out the inconsistency. I haven't browsed all the 
code, but ASCII is both CP1252 and UTF-8.