C++ and translations

[Geert Janssens]

Hi Graham,

Thanks for your feedback. It's most welcome.

On zondag 23 april 2017 01:32:33 CEST Graham Menhennitt wrote:
> > 2. c++ makes it very easy to compose strings by either summing them (strA
> > +
> > strB) or streaming them (strA << strB).
> 
> Don't do this! Some things we say in English are idiomatically
> structured in a different way in other languages. As a very simple
> example, in English we might say "There are %d items in this %s". In
> another language, they would say "in this %s there are %d items". If you
> concatenate strings, this doesn't work.

Obviously. I'm well aware of this and was mostly trying to express that what I 
had imagined so far wasn't satisfactory. Boost::Locale is clearly the better 
answer.
> 
> > 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
> 
> I wouldn't worry about translating exception messages. Firstly, users
> should never see them. Secondly, even if they do see them, it's usually
> easy enough to get their meaning - most people (especially ones likely
> to be using GnuCash) have at least a rudimentary understanding of
> English. Lastly, it makes reporting of bugs more difficult. If a German
> user reports that they've seen error "XXX", it won't match any reports
> of English users seeing "YYY" even though it's the same error.
> 
Hmm. I'm in two minds about this.

If the German user reports a (low level) exception message in German, we can 
look it up in our message catalog as well. This is no different from them 
reporting the contents of a high level (user oriented) message right now in 
German.

On the other hand I wasn't considering low level error messages, that at best 
would go into our log file. We're also leveraging exceptions at a much higher 
level in our code. When such an exception is thrown the direct result is 
informing the user via a dialog window. It only seems convenient  to use the 
exception message straight away there because the point where it's thrown has 
more detailed context and state than the catch block may have, depending on 
how close it is to the throw in the call chain.

> Another consideration is the set of tools to allow translations by third
> parties. As a developer, you want to be able to ship a set of
> translatable strings to a native speaker who isn't familiar with
> software development or GnuCash. They have to translate using some tool
> and ship the translated strings back to you. There are third party (some
> non-free) tools to do this but I can't give any recommendations there.

True. This issue is not c++ specific though. Our current c/guile code mix is 
in the same situation. What we have now is not optimal but won't be better or 
worse either for our c++ translations. That is, our message catalog is 
published on the gnu translation project from where translators can download 
and translate it. Updates can be posted in our bugzilla database. We have a 
complete wiki page with guidelines and suggestions on this topic:
http://wiki.gnucash.org/wiki/Translation

As said this is not optimal but more or less works. One day I'd love to have a 
discussion on how this could be brought into the modern age. Unfortunately I 
have currently too many other things to finish to initiate/moderate such a 
discussion at this point. :( If others want to pick this up that would be 
great.

Geert