Language Translation Patch, second attempt
Yuval Levy
attached is my second attempt at patching the source tree so that also
strings outside of wxWidgets can be translated.
This one should work on Windows (or at least not break anything) within
the SDK. Please test on OSX too.
If somebody wants to improve FindGettextLibs.cmake to better support
Windows, that's optional but welcome.
Please test.
Yuv
Rogier Wolff
On Wed, Oct 07, 2009 at 05:26:48PM -0400, Yuval Levy wrote:
> +// gettext for internalization of strings
> +#include <libintl.h>
> +#define _t(String) gettext(String)
Is this the norm in internationalization of programs. Instead of
having all those libs, translation files etc etc. I would like to have
the option of simply compiling and using the program in it's native
language:
#ifdef CONFIG_USE_GETTEXT
#include <libintl.h>
#define _t(String) gettext(String)
#else
#define _t(String) String
#endif
This would allow me to configure MY build without the dependency
on the gettext library, and maybe someone else worries about
the size of the translation files.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Kornel Benko
Yuval Levy
> Why not use FindGettext.cmake?
because to my understanding FindGettext.cmake finds the tools, not the
library, and this is why FindGettextLibs.cmake does - at least on Linux
and BSD.
For Windows both did not work, so I hard-coded the results in the main
CMakeLists.txt.
For OSX I don't know, I'm waiting for feedback before committing the fix
and make also those strings that are not directly part of the wxWidgets
app translatable.
Yuv
Yuval Levy
>
> On Wed, Oct 07, 2009 at 05:26:48PM -0400, Yuval Levy wrote:
>> +// gettext for internalization of strings
>> +#include <libintl.h>
>> +#define _t(String) gettext(String)
>
> Is this the norm in internationalization of programs. Instead of
> having all those libs, translation files etc etc. I would like to have
> the option of simply compiling and using the program in it's native
> language:
>
> #ifdef CONFIG_USE_GETTEXT
> #include <libintl.h>
> #define _t(String) gettext(String)
> #else
> #define _t(String) String
> #endif
>
> This would allow me to configure MY build without the dependency
> on the gettext library, and maybe someone else worries about
> the size of the translation files.
I see the benefit of configuring the use or not of gettext /
translations - I personally have no use for translations and indeed
would prefer a build with less dependency and less disk usage.
Configuring it here, however, won't take away the bulk of the
translation and the dependency that already exist trhough wxWidgets if I
understand correctly.
So to do it right, I'd have to find a way to configure wxWidgets not to
use gettext and not to do internationalization either. Any help on that?
I have submitted this as a patch and not committed it right away because
I am not sure that the way I have implemented this is optimal.
Maybe there is a better place for this include/define in some common
header (it is currently at the level of the individual file to be
translated)?
I will adapt the patch to be configurable as above, but I don't think
this is the last step in making internationalization optional.
I am a C++ newbie frying his brain on an itch to understand why C++ is
so highly regarded amongst programming languages. If the byproducts of
my frying brain are helpful to the project, good. If they are not,
that's not critical. And if feedback like yours brings about a better
solution, I'm happy to learn from you in the process and update the patch.
Yuv
Yuval Levy
> Am Thursday 08 October 2009 schrieb Yuval Levy:
>> Kornel Benko wrote:
>>> Why not use FindGettext.cmake?
>> because to my understanding FindGettext.cmake finds the tools, not the
>> library, and this is why FindGettextLibs.cmake does - at least on Linux
>> and BSD.
>
> with libraries.
maybe it is because the gettext libraries are used by so many packages
that you already have them on all machines you tested with?
when I first changed the code, I did not even bother with CMake. I
simply assumed that gettext was already used/found with wxWindows. THen
on Windows, despite gettext in the SDK, I had an error. So I added
FindGettext.cmake and looked what it generates. Still did not help
Windows. So I googled further and found FindGettextLibs.cmake. I
replicated the values that it created in Ubuntu to the Windows
equivalent and bingo, it worked. The ultimate test would be to try it on
a machine without gettext.
Yuv
T. Modes
> attached is my second attempt at patching the source tree so that also
> strings outside of wxWidgets can be translated.
>
> This one should work on Windows (or at least not break anything) within
> the SDK. Please test on OSX too.
>
I added the string to the .po-file).
Thomas
Yuval Levy
T. Modes wrote:
> it compiles on Windows, but the string does not get translated. (Yes,
> I added the string to the .po-file).
thanks for the feedback. I think now it should be fixed. I found a
number of issues:
- I forgot to set the bindtextdomain and textdomain in the patch (I am
still not sure if I am setting them at the right place).
- the folder with the translations was not properly #defined by the
CMake Build.
- somehow the string already existed in the .po-file, but it had a %s in
it that should not be there.
rather than working blind, this time I actually installed support for
multiple language on my Ubuntu box. It's just disk space...
please try again. thank you for your patience.
Yuv