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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
