Fwd: C++ and translations
parexus at gmail.com
Sat Apr 22 13:29:45 EDT 2017
This should have gone to the list.
On Apr 22, 2017 13:28, "David Raker" <parexus at gmail.com> wrote:
Not sure if you've looked at it, but I think Boost.Locale might be what you
are looking for. It uses gettext as so:
cout << translate("Hello World") << endl;
I haven't actually used it, but the documentation is here:
On Apr 22, 2017 12:43, "Geert Janssens" <geert.gnucash at kobaltwit.be> wrote:
> 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
> 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
> macros. However
> 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_).
> 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
> again. Should be instead create a gnc equivalent of the glib/gi18n.h but
> 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
> the qof/engine c++ work is marked as such. So I'd like to have some
> on this. Relative merits/drawbacks of either concept. Things like that.
> Personally I think it's nice if internal error messages can be reused
> user feedback. But perhaps that's not always a good idea ?
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel