[bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH

[Bruno Haible]

Update of bug #59658 (project gettext):

                  Status:          Ready For Test => In Progress            

    _______________________________________________________

Follow-up Comment #2:

> this still leads to unreproducible builds when LINGUAS contain automatically
generated PO files (e.g en@quot) and the POT file is generated/updated at
build time (e.g. building from a vcs checkout where the POT file isn't present
or up to date), as the contents of that field are used to fill
PO-Revision-Date when the PO file is created with the --no-translator option.

Indeed, yes. Well spotted.

> The attached patch implements the default use-case of SOURCE_DATE_EPOCH

This is a bit complex. I claim there is a simpler solution.

In https://savannah.gnu.org/bugs/?49654 I wrote:
"The POT-Creation-Date is important information for a translator, so that she
knows whether to review the entire file or not."

Similarly, the PO-Revision-Date is important information for a translator, so
that she knows whether she updated the file after she got a new POT file.

But in this case (en@quot catalog), there is no translator. Therefore no
PO-Revision-Date is needed.

Now, let's look at the steps:
1. xgettext produces a POT file with a POT-Creation-Date (current date) and
with a dummy PO-Revision-Date (YEAR-MO-DA HO:MI+ZONE).
2. en@quot.po is created through

msginit -i gettext-runtime.pot --no-translator -l en@quot -o - 2>/dev/null \
| sed -f en@quot.insert-header \
| msgconv -t UTF-8 \
| msgfilter quot

3. en@quot.gmo is created through

rm -f en@quot.gmo
msgmerge --for-msgfmt -o en@quot.1po en@quot.po gettext-runtime.pot
msgfmt -c --statistics --verbose -o en@quot.gmo en@quot.1po
rm -f en@quot.1po


Should the PO-Revision-Date be present after step 1? Yes, since the same POT
file is used by the translators.

Should the PO-Revision-Date be present after step 3? No, since it is a binary
file that will be installed and should therefore not contain such a date.

Should the PO-Revision-Date be present after step 2? No, since this file is
present in tarballs, and the date of production of the tarball is irrelevant.

Where in step 2 should the PO-Revision-Date be removed? The msginit step seems
to be the right place, since the information that it's not for a translator is
present there (command-line option '--no-translator'). No need to add another
step in the pipe.

So, instead of the patch that you propose, I would prefer a simpler approach:
If msginit is invoked with option '--no-translator', it omits the
PO-Revision-Date from the output.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59658>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/