GNOME Bugzilla – Bug 745941
Review of po Headers / make pot
Last modified: 2018-06-29 23:39:18 UTC
while working on bug 745597, I got the warning: header field 'Project-Id-Version' still has the initial default value It should be set by xgettext. We have to set it somewhere to become gnucash-2.6. Comparing the file with others, I saw several outdated strings. Report-Msgid-Bugs-To This has already been filled in by xgettext. It contains an email address or URL where you can report bugs in the untranslated strings E.g. we should set "Report-Msgid-Bugs-To: https://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash&component=Translations\n" see https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html On a first glimpse, I believe, our make pot process is somewhat outdated. Approach: 1. Fix the variables in our make pot process. 2. Review and update existing po files
creating new po files with msginit -i../build/po/gnucash.pot -lse_SE results in se_SE.po: # Northern Sami translations for GnuCash package. # Copyright (C) 2015 THE GnuCash'S COPYRIGHT HOLDER # This file is distributed under the same license as the GnuCash package. # Frank Ellenberger <frank.h.ellenberger@gmail.com>, 2015. # #. customers-only)) ;-- see above #: /home/frank/git/gnucash/po/../src/report/business-reports/taxinvoice.scm:163 msgid "" msgstr "" "Project-Id-Version: GnuCash 2.6.5\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2015-03-14 22:23+0100\n" "PO-Revision-Date: 2015-03-14 22:44+0100\n" "Last-Translator: Frank Ellenberger <frank.h.ellenberger@gmail.com>\n" "Language-Team: Northern Sami\n" "Language: se_SE\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n" #. Business options #: /home/frank/git/gnucash/po/../src/app-utils/app-utils.scm:302 #: /home/frank/git/gnucash/po/../src/business/business-gnome/gncmod-business-gnome.c:117 msgid "Business" msgstr "" : So many fields are initialized in a proper way. So I adjusted wiki...Translation to suggest its use. But there are 2 bugs in our current pot: 1. the comment from taxinvoice.scm:163 in the header 2. absolute pathes in all references - we removed them already from a few recent submissions.
1. the comment from taxinvoice.scm:163 in the header got fixed in commit 3f905e7
I have been playing around with the intltool stuff with respect to this bug. The "Report-Msgid-Bugs-To line can be set automatically by updating the file po/Makevars Similarly the Project_Id-Version can be set automatically by adding the xgettext command line parameters --package-name and --package-version to the xgettext invocation. I have a patch for these two issues almost ready. However I'm holding it off because of the last issue regarding the absolute paths that get introduced when calling "make pot" out of tree. I have dug a bit deeper in this as well and this behaviour is hard-coded in intltool-update. I don't know if this is a bug or intended behaviour. I actually found 2 issues when building out of tree: 1. the inclusion of paths from build directory to source directory (the "absolute paths" issue already mentioned above) 2. po/Makevars not being found Regardless this means the intltools as they are now can't be used directly outside of the source tree. We can work around this in one of two ways: 1. either explicitly switch to the source directory before calling intltool-update 2. add code in the build scripts that - makes Makevars available in the build directory - removes the extra path components from the generated pot file afterwards Apart from whether it is desirable to write directly to the source tree in case of an out-of-tree build, I haven't tested either scenario yet to see what impact they have on make distcheck.
Unfortunately this is getting messy... Both my workarounds would require changes to po/Makefile.in.in. However that file is not under version control. It's delivered by intltool and gets overwritten by each call to intltoolize and subsequently by each call to our autogen.sh. So getting either fixed would mean we'd have to patch Makefile.in.in during autogen.sh. That's thin ice since I have no idea if the provide Makefile.in.in is sufficiently the same for all versions of intltool on all platforms we support. There is another Makefile.in.in which is part of glib_gettextize. This file appears to be more smart about the pot file always being in the source tree. I tried to tweak autogen.sh just enough so intltoolize doesn't overwrite Makefile.in.in which is installed by the call to glib-gettextize. Subsequent runs of configure will however fail now complaining that Makefile.in.in is not generated by intltoolize. So you clearly can't use intltoolize only partly. It's an all or nothing thing. And that leads to the next question - what added value does intltool bring us compared to plain (glib-)gettext tools ? Unfortunately I don't have the answer (yet) as I don't know these parts or the autotools chain well.
Just in case somebody else is following, the link to our teatime talk before Geerts last comment: http://lists.gnucash.org/logs/2015/04/2015-04-01.html#T11:04:49 After that I updated http://wiki.gnucash.org/wiki/Translation#Background again. Abstract: I suspect intltool was required at times, where xgettext did only understand .c syntax and no .scm, .desktop and other file formats used in GnuCash. IMHO we can drop intltool today in gnucash.git, but not in gnucash-docs. I will do some testing in the next days. As we do translation stuff on maint, changes on master would stay untested for long time, but I can publish my result in a maint based branch a) to gnucash or b) at https://github.com/fellen/gnucash.
See https://bugzilla.gnome.org/show_bug.cgi?id=759844#c4 for the other side.
I have recently dropped using intltool in favour of using gettext directly. In addition I have added fixes to set both of - Project-Id-Version - Report-Msgid-Bugs-To while generating the pot. I have verified on my system the issue of absolute paths in POTFILES.in, pot and po files is gone. I believe with that we can (finally!) close this bug.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=745941. Please update any external references or bookmarks.