Comment changes in POT files make ISO builds non-reproducible
Sometimes we update a program of ours and as a result the line numbers encoded in comments, in the POT file generated by
refresh-translations, differ. And then POT + PO files will get updated every time we build an ISO, resulting in non-reproducible builds. This happens quite frequently (e.g. yesterday, and generally I’m baby-sitting Jenkins results closely enough to notice, and then I run
refresh-translations, commit and push to fix the problem. It’s a waste of my time, and I don’t even want to consider sharing this dumb work better. We’d better simply eliminate the root cause of this problem :)
To this end, I think we instead should:
refresh-translationsignore changes in comments by default, just like it already ignores changes in the POT creation date header; this way ISO builds won’t be made needlessly unreproducible by such trivial changes;
--forceoption, that we’ll use in the release process to ensure we regularly update even those usually ignored comments.
I guess both
intltool_update_pot functions and the
refresh-translations script need to be changed. Perhaps
import-translations as well but I’m less sure (one would need to look exactly when/how/why we run it to make a good decision).
Who wants to do it? Either anonym or Ulrike, I guess? If you prefer I can handle it myself, stealing from your time budget.
Blocked by Tails -
#2 Updated by Anonymous 2017-09-05 19:37:53
- Status changed from Confirmed to In Progress
- Assignee set to anonym
- QA Check set to Ready for QA
- Feature Branch set to 451f:tails/bugfix/12641+potfile_line_comments
I was not really able to test this in a real life environment, as I never update the translations of our programs. However, I tried using some fake pot files and it seemed to work. Can you please review and improve this if necessary? Thanks!
#7 Updated by anonym 2017-09-12 23:26:47
- Assignee changed from anonym to intrigeri
Note: the feature branch was force pushed right before posting this comment! Pull!
I hope it also does what it should — I must admit I haven’t felt I’ve had enough time (and the time has been so fragmented!) to really get to understand what’s going on in these scripts, mostly due to my unfamiliarity with this side of the gettext toolbox. But I am on the optimistic side of hope, at least! :)