I've been discussing with Steven Sheehy (linuxdc++) the possible replacement of stringdefs.h/cpp
with gnu gettext. I18n in dc++ currently suffers from a few issues such as parameter ordering (some
translation require reordering of %-arguments), memory managment issues (manual buffer allocation et
al), poor distribution model (user needs to know english to install language file).
By using gettext we solve the distribution issue (and add another - a new release is needed to
update a language) - language files are delivered together with dc++ in the installer. We also get
to use existing translation tools, of which a few even work with windows (www.poedit.net). Steven
pointed out another advantage - with gettext the actual string can be seen directly without having
to look it up in the enum table.
There are a few issues though:
* We still have to deal with formatting. Currently we either do STRING(XXX) + Util::toString(yyy) or
sprintf(buf, CSTRING(XXX), yyy), both of which need to go away.
- boost::format solves both these things but introduces boost as dependency for the dcpp/ core as
well. steven doesn't like that, unless boost is used for more than just formatting. Some useful
boost libraries unfortunately require compiling which is slightly messy on windows - obviously using
the header-only libraries is a good thing in terms of code correctness and platform independence so
those could obviously be used.
- I don't know of any other reasonable formatting solutions (steven suggested printf which on most
unices supports positional arguments by using %m$ but that's not supported on unix and still
requires manual memory managment...)
- One possible solution would be to use our own string replacement routines ("%[xxx]")...this is
slightly ugly since we have to create a map each time and convert the arguments to strings manually
(Util::toString), and we lose some of the tooling support that gettext offers for standard format
strings.
* Windows support in the gettext library is scarce, so a way to convince it to use a particular
language and load it from the correct place (since gettext has its own specific opinion about where
language files should be) needs to be found. This shouldn't be too hard though...
* Windows and unix use different names for locales, and gettext uses the locale name to figure out
where to load the file...
* All of the existing STRING(xxx) need to be replaced by their respective texts from stringdefs,
while paying attention to arguments etc (so a simple script won't be able to do it). This is quite a
lot of work...anyone interested?
* A script should be made to convert the current xml translations - I think there are some 30
translations already so losing them wouldn't be nice...again, anyone interested?
* dcpp/ and win32/ would have separate translation files - but since the strings for both the win32
and linux gui are similar, it would be nice to have a way to synchronize those strings every now and
then. I'm not sure if there are some tools to merge all equal strings from two po's and leave the
rest alone, but if there aren't a script would be nice here too...
/J
|
