GNUCash translation status

Christian Stimming stimming at tuhh.de
Sun Jan 20 17:15:58 EST 2008


Am Sonntag, 20. Januar 2008 16:09 schrieb Derek Atkins:
> Claude Paroz <claude at 2xlibre.net> writes:
> >> Is your process flexible enough to add this kind of step?
> >
> > Currently not.
> > But things are now clear enough, thanks Derek. I've entered a bug report
> > in Damned Lies, so we can track this question there.
> >
> > http://bugzilla.gnome.org/show_bug.cgi?id=510427
>
> Cool.
>
> > Personally, I'd rather have the intltool/guile problem resolved instead.
>
> I think that's the longer term solution, but frankly I think fixing
> damned-lies is probably going to be faster.  I suspect that
> fixing intltool will take a few more years, because not only does
> it need to be fixed upstream but then it needs to trickle down
> into distributions.

Oh, right, absolutely. I was going to mention that of course it would be nicer 
for gnucash to get rid of our hand-made intl-scm/guile-strings.c generation 
and replace it by xgettext. We would hopefully gain e.g. correct references 
to the (scheme) source code location in the po files, including line numbers. 
However, the intltool-scripts are a necessary prerequisite for that. 
Unfortunately we cannot consider switching our string extraction as long as 
the main distributions still have intltool that cannot handle this.

Hence, for now either Damned-Lies needs to have extra rules for gnucash. In 
theory we could add guile-strings.c to SVN as well, but I'm not sure whether 
this is sufficient and also that file changes often enough automatically so 
that it's the classical case for *not* going into version control. We would 
rather like to avoid that. Sorry for that.

Christian


More information about the gnucash-devel mailing list