Am Sonntag, 20. Januar 2008 16:09 schrieb Derek Atkins: > Claude Paroz <[EMAIL PROTECTED]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
