2

I want to submit a PR to a github-hosted project (timeshift) that uses po and pot files for translation. I have never encountered these before. One of my changes is to UI (this is backup software and I've added an option to skip jobs when the machine is on battery).

The .pot file appears to be the 'master'. It is generated by a script, it seems. My change has been detected and correctly two strings have been added to the .pot file.

the script to make the project then generates a lot of .po files, and they are changed. I suppose this is unavoidable and correct, since I have added two strings that need translation.

However, they are all committed and part of my pull request. This doesn't seem right, because any changes to translations before my PR is reviewed are then going to require merging, it looks like a lot of work, and I suppose/guess that the project developer does not want to concern himself with translations very much.

Is this just the way it is, or is there a workflow I don't know about? Should I somehow avoid marking my string changes for translation, and then make that a second PR, to keep my logic changes separated from the noise of translation?

I have not had any response from the project developer.

Tim Richardson
  • 6,608
  • 6
  • 44
  • 71
  • If `.po` file are generated from `.pot` files, then the `.pot` files are sources and should be committed, but the `.po` files are not and should not be committed. Uncommitted files won't exist in clones, and if you mark them via `.gitignore`, when they do exist in work-trees, they'll continue to be un-committed, un-tracked, and quietly not-complained-about. However, if not everyone has the tools that *generate* `.po` files from `.pot` files, you have a dilemma. – torek Aug 12 '19 at 00:55
  • The dilemma is: should you commit the generated files and live with the noise? Or, should you just tell all the people who lack the tool: *too bad, go get the tool?* – torek Aug 12 '19 at 00:55
  • the po files are source files too, because they contain the actual translations. The .pot file holds the strings which need translation. I don;t know by what magic .po files are changed when new strings are added to .pot. However, it doesn't really matter. These means of updating .po files is part of the project. But if I .gitignore them, my branch will fall behind translations which doesn't seem right. This is why I want to hear from others who have actually dealt with this. – Tim Richardson Aug 12 '19 at 01:11
  • I have learnt that I am dealing with 'gettext', and I found this: https://stackoverflow.com/a/51769371/401226 with the suggestion that generating po files should be separated from compiling the code. – Tim Richardson Aug 12 '19 at 01:21
  • Wait for feedback to the maintainer or look at earlier PRs. There is no established workflow for this problem. It's rather a matter of taste. – Guido Flohr Aug 12 '19 at 08:21

1 Answers1

1

2019: For your PR branch, you do not need to commit the .po files. As you have found, they will be regenerated from the Makefile, and can be committed by the one integrating your PR.

Once your PR integrated (with the generated .po files updated), you can rebase your working branch, and get said updated .po files then.

Incidentally, The Git project itself has to deal with this workflow, and recently changed it.

With Git 2.37 (Q3 2022), a workflow change for translators are being proposed.

See commit e2f4045, commit b9832f7, commit 5377abc, commit 6dd9a91, commit 1cc0425 (26 May 2022) by Ævar Arnfjörð Bjarmason (avar).
See commit fbb3d32, commit e448263, commit 15fe406, commit 9f55578, commit ea3f639 (26 May 2022) by Jiang Xin (jiangxin).
(Merged by Junio C Hamano -- gitster -- in commit 28db3b7, 03 Jun 2022)

po/git.pot: don't check in result of "make pot"

Signed-off-by: Ævar Arnfjörð Bjarmason
Signed-off-by: Jiang Xin

Remove the "po/git.pot" file from being tracked, which started with dce37b6 ("l10n: initial git.pot for 1.7.10 upcoming release", 2012-02-13, Git v1.7.10-rc0 -- merge).

The reason the po/git.pot started being checked in was because the po/*.po files were changed a schema where we'd generate them from a known-good snapshot of po/git.pot, instead of each translator running "make pot" themselves.

This makes sense, but we don't need to carry this file in-tree just to achieve that aim, and doing so has resulted in a significant amount of "diff churn" since this method of doing it was introduced:

$ git log -p --oneline -- po/git.pot|wc -l
553743

We can instead let l10n contributors to generate "po/git.pot" in runtime to update their own "po/XX.po", and the l10n coordinator can check pull requests using CI pipeline.

This reverts to the schema introduced initially in cd5513a (i18n: Makefile: , 2011-02-22, Git v1.7.5-rc0 -- merge) (i18n: Makefile: "pot" target to extract messages marked for translation, 2011-02-22).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks. I have added an option to build without generating the translation files. I think I should kill my current PR and start again. – Tim Richardson Aug 12 '19 at 05:48
  • 1
    @TimRichardson No, you can simply reset your PR branch locally, remake your work, and then force push: your PR will be automatically updated. – VonC Aug 12 '19 at 05:59
  • 1
    It should also be mentioned that there is obviously a flaw in the build system of the project in question. `.po`, `.pot`, and `.mo` files should never be updated automatically, exactly because of this. It makes them dirty on every source code change which is not the desired behavior. See my answer https://stackoverflow.com/a/51769371/5464233. – Guido Flohr Jun 03 '20 at 07:02