Fwd: C++ and translations

[David Raker]

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:

http://www.boost.org/doc/libs/1_61_0/libs/locale/doc/html/me
ssages_formatting.html

On Apr 22, 2017 12:43, "Geert Janssens" <geert.gnucash at kobaltwit.be> wrote:

> Hi,
>
> 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
> wondering...
>
> 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
> 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_).
> 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++
> alternative.
>
> 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 ?
>
> Geert
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>