Absolute paths in POT (and PO) file for LaTeX type with po4a, not for text

[vermeeren]

Hi,

Recently I decided it's a good idea to modernise my usage of po4a, switching to the single utility po4a with the configuration file instead of calling the different utilities manually.

With the old way of calling po4a, all types were set to LaTeX, although one of the files was actually text, as this is a limitation with the old utilities when a single PO file is desired.

Oddly enough however with the new po4a configuration the #: references in the POT and PO are suddenly absolute path instead of relative path, but only for the LaTeX type. The text type is still relative as usual. This is rather problematic because we store the PO files in git, which results in the path changing all the time.

[po4a_langs] $(langs)
[po4a_paths] po/en.pot $lang:po/$lang.po

[options] -k 0 --porefs file --master-language en

[type: text] script/po_strings.txt $lang:build/script/po_strings.txt
[type: latex] src/0101-preamble-pagenumber.tex $lang:build/0101-preamble-pagenumber.tex
[type: latex] src/0201-document-title.tex $lang:build/0201-document-title.tex
[type: latex] src/0300-header-title.tex $lang:build/0300-header-title.tex
[type: latex] src/0400-items-start.tex $lang:build/0400-items-start.tex
[type: latex] src/0600-terms.tex $lang:build/0600-terms.tex

Part of the resulting diff, slightly sanitised. (In the old version linenumbers were default, disabled them with transition to po4a configuration file usage.)

diff --git a/po/nl.po b/po/nl.po
index bcf24ef..372aeae 100644
--- a/po/nl.po
+++ b/po/nl.po
 #. type: Plain text
-#: script/po_strings.txt:2
+#: script/po_strings.txt
 msgid "str_bic='BIC'"
 msgstr "str_bic='BIC'"

 #. type: ofoot{#1}
-#: src/0600-terms.tex:18
+#: /home/melvin/dev/.../src/0101-preamble-pagenumber.tex
 msgid "\\thepage{} of \\pageref{LastPage}"
 msgstr "\\thepage{} van \\pageref{LastPage}"

Edit: I realise the src file changes here. The previous version was generated with 0.55 from buster in some odd manual CLI way specifying all the files on the CLI, the path was incorrect. The new version gets the path correct, it's just an absolute one now.

I tried checking the source code of po4a, but it seemed like it handles thing in a generic way and the filetype module just handles the details. Only thing regarding absolute paths I found is in TransTractor.pm lines 303 and 314.

    sub _input_file {
        my $filename = $_[0];
        return $filename if ( File::Spec->file_name_is_absolute($filename) );
        foreach ( ( $destdir, $srcdir, $calldir ) ) {
            next unless defined $_;
            my $p = File::Spec->catfile( $_, $filename );
            return $p if -e $p;
        }
        return $filename;
    }

    sub _output_file {
        my $filename = $_[0];
        return $filename if ( File::Spec->file_name_is_absolute($filename) );
        foreach ( ( $destdir, $calldir ) ) {
            next unless defined $_;
            return File::Spec->catfile( $_, $filename ) if -d $_ and -w $_;
        }
        return $filename;
    }

Could it be the text type bypasses the TransTractor? That would explain the current behaviour. Is it possible to output the relative file path (based upon config file paths) to the POT and PO files? I suspect that is desired behaviour for most.

po4a version 0.61 from Debian buster-backports.

Thanks for checking!

[mquinson]

Hello, sorry for the delay.

This was also reported recently as https://bugs.debian.org/998196 and I fixed it in b0f1df3

The bug was in the TeX module, not in the main parts. The conversion from relative to absolute is done with kpsewhich in that TeX module, which is probably why you didn't find it.

The regression was introduced when I cleaned up the way input and output files are handled so that srcdir and dstdir actually work. That is why po4a now handles absolute paths internally. To not propagate these absolute path, the TransTractor::read() function now takes a third parameter that is the short filename to use in the references. But actually, I did not see that TransTractor::read() is overloaded by TeX::read(). The aforementionned commit simply propagates the third parameter correctly in the overloaded version of the function.

Thanks for reporting, and sorry for not being so reactive on po4a.
Mt

[vermeeren]

@mquinson No worries, life is busy at (many) times. po4a really is very nice to use, much appreciated!