Am 22.06.25 um 19:11 schrieb Alexander Shopov: >> not .. obvious, even with `git show --ignore-matching-lines='#:' >> --color-moved`. Is there a way to enforce a stable order in the .pot >> file and/or the merged .po files? > > Sadly no. The -s/--sort-output is deprecated (plus it is counter productive). > https://www.gnu.org/software/gettext/manual/gettext.html#index-_002ds_002c-msgmerge-option > > The default is -F/--sort-by-file which is kind of saner. > https://www.gnu.org/software/gettext/manual/gettext.html#index-_002dF_002c-msgmerge-option > > It may cause jumping around in case a translatable string that was > available in one file, becomes available in a file sorted earlier > than the format but nothing is 100% proof. That is acceptable and is mitigated somewhat if the diff is viewed with --color-moved. As far as I can see, the order of files that are passed to xgettext is stable. We use $(wildcard lib/*.tcl), which is specified to produce a sorted list of file names. If xgettext doesn't do anything silly, this should produce a stable .pot file. > Sorting is not enough for sane diffs. As the location data also > contains line numbers - adding a line before a message pushes its > location down. > > The way I read your message: > - you are OK with a translator choosing to submit po-files without > location info. This will make commits and diffs shorter and more > understandable and reduces the growth of the repo The info is not > used during runtime and is easily recoverable - generate the pot and > merge the translation. > - you are at least interested in moving the infrastructure to this workflow. All correct. > In such a case next time I submit a gitk/git-gui translation I will > voluntarily remove the locations. An update of the Makefile rules would also be desirable, so that a simple `make update-po` produces the new format. -- Hannes
