I would like to fix the issue of different translations for the same string. Since nobody answered my last message, I cite it below. I'll use the second method described below. Before I write some translators documentation (where to put it ?), I'd like to have some feedback wether this is ok and maybe even answers to the questions ;-)
Georg Georg Baum wrote: > Jean-Marc Lasgouttes wrote: > >>>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> >>>>>>> writes: >> >> Angus> Why not use strings "Menu|File|Open" etc and then define an >> Angus> "en" po file. Jean-Marc has already established the precedent >> Angus> by ensuring that only ASCII characters are passed to the >> Angus> translation functions. >> >> Or we could allow for a different syntax like "To|[EMAIL PROTECTED]", where the >> part after @ is ignored in the shortcut. > > This would be specific to xforms. So we would need something similar to my > first proposal in addition. > > I investigated Angus' proposal a bit. The solution with the english > translation still has the problem that it should be used as fallback for > untranslated languages. I found out that a fallback translation is > possible with GNU gettext (see first patch). > > Questions: > 1. Do we ever use any other gettext than GNU gettext? > 2. Is HAVE_LC_MESSAGES ever undefined? > > If the answer to at least one questions is "yes", then this solution will > not work. > > A simpler version is attached in the second patch. Here remain some > questions, too: > > 1. Is it necessary to call bindtextdomain() and textdomain() again for the > english translation? As I understood the gettext documentation, these > functions are normally called only once at program startup. There must be > a reason to call them every time a translated message is requested, so I > added them a second time. > 2. In many cases the second gettext call is executed although it is not > needed. Is this a performance problem? I should probably use the profiler, > but how do I simulate a typical usage? > > Both versions work (at least on linux). I would tend towards the second > version, but if it has performance problems, we might need gettext to sort > out the right translation (first patch). > Opinions? > > The only things that still needs to be done is a bit of documentation for > the translators. Where should this be added? > > One last remark: I updated the .po files by hand, because "make update-po" > produced large changes, and running this is not possible with builddir != > srcdir. > > > Georg
