Menu
▾
▴
dcplusplus-devel
|
From: Jacek S. <arn...@gm...> - 2007-12-29 14:56:42
|
Ok, I've now committed the basic i18n support using gettext...I'm no gettext expert so there are probably better ways to go about, but it seems to be working more or less...let me know what I got wrong... What's left is the following: 1) Decide on formatting function (with positional args, preferably with automatic memory managment). Boost seems the best so far (positional params, supported by xgettext, no memory hassles) but I'm open to (msvcrt-friendly) alternatives... Steven? If boost, I'm open to using more of the boost library (pointers, threads etc), evaluating each sublibrary on its own... 2) Convert all strings to use above mentioned formatting function 3) Make a script that converts the old language files 4) Preferably create the automatic merge script for the two project guis... Anyone interested? /J |
|
From: Jacek S. <arn...@gm...> - 2008-01-24 00:01:10
|
Thanks to mikejj mainly, the transition to gettext is done as far as the source is concerned... What remains is to make a script that takes an xml file and creates a po file...I've started playing around with such a script that should be ready tomorrow, then we'll see how to proceed with the actual translations...nice work and thanks to all who contributed, both code- and discussionwise =) /J |
|
From: David G. <c0...@cs...> - 2008-01-24 10:00:58
|
I'm sorry I haven't been of more help. I thought that I would have time for it, but real life demanded more than I'd expected at the end of term. Oh well. Jacek Sieka wrote: > Thanks to mikejj mainly, the transition to gettext is done as far as the source is concerned... > What remains is to make a script that takes an xml file and creates a po file...I've started playing > around with such a script that should be ready tomorrow, then we'll see how to proceed with the > actual translations...nice work and thanks to all who contributed, both code- and discussionwise =) > |
|
From: David G. <c0...@cs...> - 2007-12-30 08:41:35
|
When you have decided what formatting function to use, I will help out with 2, 3 and 4. David (individ) Jacek Sieka wrote: > 1) Decide on formatting function (with positional args, preferably with automatic memory managment). > Boost seems the best so far (positional params, supported by xgettext, no memory hassles) but I'm > open to (msvcrt-friendly) alternatives... Steven? If boost, I'm open to using more of the boost > library (pointers, threads etc), evaluating each sublibrary on its own... > > 2) Convert all strings to use above mentioned formatting function > > 3) Make a script that converts the old language files > > 4) Preferably create the automatic merge script for the two project guis... > > Anyone interested? |
|
From: David G. <c0...@cs...> - 2007-12-30 13:36:47
|
Slightly OT, what version of the gettext tools are required? Building with scons, I get a 'xgettext: unrecognized flag "--package-name=dcpp"'. I'm using the latest precompiled binaries I could find (0.13.1), but they generate this error message. Have you compiled them yourself from the gettext 0.17 source? Naturally, I'm on win32. David |
|
From: Jacek S. <arn...@gm...> - 2007-12-30 16:18:07
|
0.17, yes...I'm compiling on linux though so it's slightly easier for me =)...it's supposed to be compileable on win32 as well so if you make some binaries, maybe it would make sense to put them up somewhere to make it easier for others... /J David Grundberg wrote: > Slightly OT, what version of the gettext tools are required? Building > with scons, I get a 'xgettext: unrecognized flag "--package-name=dcpp"'. > I'm using the latest precompiled binaries I could find (0.13.1), but > they generate this error message. Have you compiled them yourself from > the gettext 0.17 source? Naturally, I'm on win32. > > David > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > dcplusplus-devel mailing list > dcp...@li... > https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel > |
|
From: Jacek S. <arn...@gm...> - 2008-01-01 20:20:51
|
Well, if you want to, there are lots of parameter-less strings that one could start with already...3 can also be done now; as I see it, it should read the pot file and dc++-xml-file and write a po-file with all the exact matches translated, and the rest empty...unless you have a better idea... /J David Grundberg wrote: > When you have decided what formatting function to use, I will help out > with 2, 3 and 4. > |
|
From: David G. <c0...@cs...> - 2008-01-02 20:42:15
|
I've noticed that using Visual C++ 2005 Express Edition causes scons to
fail. On my machine at least. Caught me by surprise.
Removing the key (in CURRENT_USER\Software\Microsoft\Visual Studio
something) in the registry remedies the problem.
C:\dcpptrunk>scons tools=mingw
scons: Reading SConscript files ...
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 37:
ordinal
not in range(128):
File "C:\dcpptrunk\SConstruct",
line 77:
Help(opts.GenerateHelpText(env))
File "C:\Program\Python25\scons-0.97\SCons\Script\SConscript.py",
line 581:
env = self.factory()
File "C:\Program\Python25\scons-0.97\SCons\Script\SConscript.py",
line 561:
default_env = SCons.Defaults.DefaultEnvironment()
File "C:\Program\Python25\scons-0.97\SCons\Defaults.py", line 66:
_default_env = apply(SCons.Environment.Environment, args, kw)
File "C:\Program\Python25\scons-0.97\SCons\Environment.py", line 794:
apply_tools(self, tools, toolpath)
File "C:\Program\Python25\scons-0.97\SCons\Environment.py", line 137:
env.Tool(tool)
File "C:\Program\Python25\scons-0.97\SCons\Environment.py", line 1340:
tool(self)
File "C:\Program\Python25\scons-0.97\SCons\Tool\__init__.py", line 157:
apply(self.generate, ( env, ) + args, kw)
File "C:\Program\Python25\scons-0.97\SCons\Tool\default.py", line 41:
SCons.Tool.Tool(t)(env)
File "C:\Program\Python25\scons-0.97\SCons\Tool\__init__.py", line 157:
apply(self.generate, ( env, ) + args, kw)
File "C:\Program\Python25\scons-0.97\SCons\Tool\mslink.py", line 200:
include_path, lib_path, exe_path =
SCons.Tool.msvc.get_msvc_paths(env,versio
n)
File "C:\Program\Python25\scons-0.97\SCons\Tool\msvc.py", line 564:
include_path = get_msvc_path(env, "include", version)
File "C:\Program\Python25\scons-0.97\SCons\Tool\msvc.py", line 349:
return _get_msvc8_path(path, str(version_num), platform, suite)
File "C:\Program\Python25\scons-0.97\SCons\Tool\msvc.py", line 291:
dirs = _parse_msvc8_overrides(version, platform, suite)
File "C:\Program\Python25\scons-0.97\SCons\Tool\msvc.py", line 194:
settings_path = settings_path.replace(r'%' + env_var + r'%',
env_vars[env_va
r])
|
|
From: David G. <c0...@cs...> - 2008-01-02 22:02:18
|
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
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.
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.
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)
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.
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?
I'll just end this mail here while it's not a book. Sorry for this
gigantic post :)
David
Jacek Sieka skrev:
> Well, if you want to, there are lots of parameter-less strings that one could start with already...3
> can also be done now; as I see it, it should read the pot file and dc++-xml-file and write a po-file
> with all the exact matches translated, and the rest empty...unless you have a better idea...
>
> /J
>
> David Grundberg wrote:
>> When you have decided what formatting function to use, I will help out
>> with 2, 3 and 4.
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
|
|
From: Jacek S. <arn...@gm...> - 2008-01-03 09:32:39
|
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
|
|
From: David G. <c0...@cs...> - 2008-01-03 17:03:22
|
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. |
|
From: Jacek S. <arn...@gm...> - 2008-01-03 19:57:29
|
I've now added a few macros and a few translations (DownloadsFrame.cpp) which should serve as example of where we want to arrive more or less, so have a look and let me know what you think... |
|
From: David G. <c0...@cs...> - 2008-01-04 08:05:15
Attachments:
favhubsframe-splashwindow.patch
|
Here's my take on FavHubsFrame.cpp and SpashWindow.cpp. Compiling takes about one hour for me... :( I've commented out package-name in SConstruct, and added gettext_noop and N_. I've also added TFN_ for ANSI builts, which seemed to be lost. In order to i18nize the column names I just copied ResourceManager::getStrings and made some modifications to it. It shouldn't reside in FavHubsFrame, but some other more accessible place. Didn't know where to put it though. Oh, and turns out StringDefs.h isn't pure ASCII, SETTINGS_EXAMPLE_TEXT contains some characters > 127. It doesn't seem to be UTF-8. In CP1252 it renders to something like &Acute;€... Corrupt? Jacek Sieka skrev: > I've now added a few macros and a few translations (DownloadsFrame.cpp) which should serve as > example of where we want to arrive more or less, so have a look and let me know what you think... |
|
From: Jacek S. <arn...@gm...> - 2008-01-04 21:00:59
|
David Grundberg wrote: > Here's my take on FavHubsFrame.cpp and SpashWindow.cpp. Compiling takes > about one hour for me... :( I've commented out package-name in looks good in general..and yes, gcc is much slower than msvc unfortunately...gcc 4.3 should help some with variadic template params support...get a dual-core until then =) > SConstruct, and added gettext_noop and N_. I've also added TFN_ for ANSI > builts, which seemed to be lost. it would surprise me if that was the only problem with ansi builds... > In order to i18nize the column names I just copied > ResourceManager::getStrings and made some modifications to it. It > shouldn't reside in FavHubsFrame, but some other more accessible place. > Didn't know where to put it though. Moved to winutil... > Oh, and turns out StringDefs.h isn't pure ASCII, SETTINGS_EXAMPLE_TEXT > contains some characters > 127. It doesn't seem to be UTF-8. In CP1252 > it renders to something like &Acute;€... Corrupt? Should be euro signs...I changed them to escapes.. /J |
|
From: poy <po...@12...> - 2008-01-03 16:30:15
|
>> 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...) i have 0.15 here provided with Cygwin ( www.cygwin.com ) and it works fine as long as i remove that package-name argument. poy |
|
From: Steven S. <ste...@gm...> - 2008-01-01 21:18:15
|
Jacek Sieka wrote: > Ok, > > I've now committed the basic i18n support using gettext...I'm no gettext expert so there are > probably better ways to go about, but it seems to be working more or less...let me know what I got > wrong... > > What's left is the following: > > 1) Decide on formatting function (with positional args, preferably with automatic memory managment). > Boost seems the best so far (positional params, supported by xgettext, no memory hassles) but I'm > open to (msvcrt-friendly) alternatives... Steven? If boost, I'm open to using more of the boost > library (pointers, threads etc), evaluating each sublibrary on its own... > > 2) Convert all strings to use above mentioned formatting function > > 3) Make a script that converts the old language files > > 4) Preferably create the automatic merge script for the two project guis... > > Anyone interested? > > /J > 1) I've no problems with using boost. -Steven |
|
From: Jacek S. <arn...@gm...> - 2008-01-01 22:00:42
|
Boost format it is then ...%n% syntax looks nicest I think, followed by %|x|... /J > 1) I've no problems with using boost. > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X