[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH
From: |
Bruno Haible |
Subject: |
[bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH |
Date: |
Sat, 12 Dec 2020 09:00:55 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0 |
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/
- [bug #59658] xgettext and msgint don't honor SOURCE_DATE_EPOCH, Miguel Ángel Arruga Vivas, 2020/12/11
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Bruno Haible, 2020/12/11
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Miguel Ángel Arruga Vivas, 2020/12/11
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Miguel Ángel Arruga Vivas, 2020/12/11
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH,
Bruno Haible <=
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Bruno Haible, 2020/12/12
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Bruno Haible, 2020/12/12
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Miguel Ángel Arruga Vivas, 2020/12/12
- Re: SOURCE_DATE_EPOCH library code, Bruno Haible, 2020/12/13
- [WIP-PATCH v1] Re: SOURCE_DATE_EPOCH library code, Miguel Ángel Arruga Vivas, 2020/12/14
- Re: [WIP-PATCH v1] Re: SOURCE_DATE_EPOCH library code, Bruno Haible, 2020/12/15
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Bruno Haible, 2020/12/13
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Miguel Ángel Arruga Vivas, 2020/12/14
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Miguel Ángel Arruga Vivas, 2020/12/14
- [bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH, Bruno Haible, 2020/12/15