Bruno Haible wrote on Sat, 15 Jul 2017 21:24 +0200: > Daniel Shahaf wrote: > > So: should po file generation allow the caller to control the timestamp > > that would be embedded? > > No, that would be a regression for the translators. >
No, it would not. The proposed change is to set the timestamp header to a caller-provided value. Translators would not be providing a value, and therefore would not exercise the codepath being proposed for addition and would experience no change in behaviour. > > > it's plain text, and it's a small diff. > > > > This doesn't scale. (For example, in my use-case, I'm dealing with a > > 5000-line unified diff full of one-line changes in date strings and C > > comments and any number of other things. My goal is to get the number of > > lines down to zero.) > > Then you will have to filter out the one-line changes that are not > important to you. > As I said, this doesn't scale. I have multiple upstreams to filter in this way; I assume others are in my position too; and the filter would be a moving part in itself. To put it differently: if I have to use diffoscope to see that two things are equivalent, I've already lost. There is a world of difference between things that are equal according to cmp(1) and things that are equal according to diffoscope(1): the latter notion of equivalence is much weaker in practice. (E.g., it doesn't allow for content addressing, it makes audits harder, etc.) > The purpose of tarballs is distribution to developers, translators, > and distros. > > The purpose of Makefile.in.in rules that generate .pot files is: > The .pot files are the starting point for translators (or for the > Translation Project, which extracts the .pot files and makes them > easily accessible to the translators). > The date of the POT file is important info for the translators. > The date would remain available to translators: whoever generates the tarball for distribution to translators not be using the new codepath. > This is the main workflow. It allows for reproducible builds (through > the timestamp filtering now built into msgfmt). > > > I am asserting that there is another workflow which would be simpler if > > .po file headers were also reproducible. > > You'll have to adapt. Accept the main workflow as it is. You'll have to adapt. Keep the main workflow unperturbed but add a modified workflow to cater for different use-cases. tl;dr: The proposed change is 100% backwards compatible. Daniel (I'll slow down my replies for a bit to give others a chance to chime in.)
