Update 'dprint fmt' results for .po files

[djmitche]

I cleared $HOME/.cache/dprint on my machine and re-ran dprint check (which had previously succeeded), and it generated these changes.

Somewhat aside, it's frustrating that dprint is very much a moving target, and moves at a different pace than our PRs. As a concrete example, this PR will also fail due to #2165. And, the check is required to merge, so until that's fixed we can't merge anything.

[mgeisler]

I cleared $HOME/.cache/dprint on my machine and re-ran dprint check (which had previously succeeded), and it generated these changes.

Oh, that's not good! I haven't noticed problems with the caching myself, but that is of course not a guarantee for anything :smile:

Somewhat aside, it's frustrating that dprint is very much a moving target, and moves at a different pace than our PRs. As a concrete example, this PR will also fail due to #2165.

We should fix this so that we get stable and consistent results. The formatting plugins for dprint are already versioned, so I think we simply have to pin the rustfmt binary to a particular nightly build. I can make a PR for that!

[djmitche]

I suspect this particular issue is actually a msgfmt version issue?

⸩ msgfmt --version
msgfmt (GNU gettext-tools) 0.21

[djmitche]

Huh, same version in CI

▶ Run msgfmt --version
msgfmt (GNU gettext-tools) 0.21

[djmitche]

Dprint uses msgcat and not msgfmt but they are both in gettext-utils so the versions are the same.

I can confirm that msgcat - itself will reformat the files as shown in this PR:

⸩ msgcat - < po/de.po > t                                                                                                               
⸩ mv t po/de.po 
⸩ git diff
diff --git po/de.po po/de.po
index 9b2ab992..cfa8f599 100644
--- po/de.po
+++ po/de.po
@@ -4008,4 +4008,4 @@ msgid ""
 msgstr ""
-"Das Hinzufügen von `#`, z. B. `{a:#?}`, ruft ein „hübsches "
-"Druckformat“ (pretty print) auf, das einfacher zu lesen ist."
+"Das Hinzufügen von `#`, z. B. `{a:#?}`, ruft ein „hübsches Druckformat“ "
+"(pretty print) auf, das einfacher zu lesen ist."
 
@@ -8928,4 +8928,4 @@ msgstr ""
 "erstellt hast. Allerdings kannst Du die Werte sowohl von `a` als auch von "
-"`s` sicher lesen. Weitere Einzelheiten werden im Abschnitt "
-"„Ausleihenprüfer“ (borrow checker) erläutert."
+"`s` sicher lesen. Weitere Einzelheiten werden im Abschnitt „Ausleihenprüfer“ "
+"(borrow checker) erläutert."

which suggests that there is some different gettext-utils configuration here?

I wondered if it is simply that the default for [-w](https://www.gnu.org/software/gettext/manual/gettext.html#index-_002dw_002c-msgcat-option) is based on the screen width somehow, and that differs between CI and my terminal. However, trying a number of -w values locally does not reproduce the wrapping currently in main. The closest is -w 79, but that still leaves the diff shown above.

Perhaps this has something to do with the calculation of unicode line widths? Setting LC_ALL to various things (C, en_US.UTF-8, es_ES.UTF-8, etc.) doesn't seem to affect the output.

Other ideas?

[djmitche]

See #2173.