C++ and translations

[Geert Janssens]

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