C++ and translations
geert.gnucash at kobaltwit.be
Sat Apr 22 12:43:13 EDT 2017
While dabbling in the c++ conversion work of gnucash it occurred to me most of
our translatable strings are gettext wrapped char*'s.
However the native string format for c++ is std::string. And that got me
So here's a few questions that came up in this regard:
1. is there a c++ way to handle translations ? As far as I'm aware gettext
can't handle std::string objects directly, so we have to pass it the ->c_str()
function result. This is not always very nice.
2. c++ makes it very easy to compose strings by either summing them (strA +
strB) or streaming them (strA << strB).
This is much easier than c's string formatting using %s, %d and related format
gettext ("In sentence %d, we need number %i")
gives a full sentence in our po file whereas
gettext ("In sentence ") + varA + gettext (", we need number ") + varB
results in two separate and essentially untranslatable strings instead.
What's the c++ answer to this ?
3. Our current c code includes <glib/gi18n.h> to get a couple of useful
shorthand macros to the most common gettext functions (N_, _, C_, Q_). However
that file is from glib, which we're trying to eliminate. I found some c++
files include <libintl.h> instead, which brings in gettext, but not the
convenience macros. I'm not a fan of redefining the same macros over and over
again. Should be instead create a gnc equivalent of the glib/gi18n.h but that
omits the glib.h inclusion and reference that file in all c++ files needing
translation support ? Perhaps not needed of course if there's a better c++
4. When we throw exceptions, we pass a message explaining the reason the
exception was thrown. I have been leveraging these messages to inform the
users directly of why a certain action failed. That of course requires the
exception messages are translatable. I note none of the exception reasons in
the qof/engine c++ work is marked as such. So I'd like to have some discussion
on this. Relative merits/drawbacks of either concept. Things like that.
Personally I think it's nice if internal error messages can be reused towards
user feedback. But perhaps that's not always a good idea ?
More information about the gnucash-devel