Hi,
On Wed, Mar 12, 2025 at 01:06:11PM +0800, Maytham Alsudany wrote:
It might also be worthwhile to forward your message to
debian-i18n@l.d.o, since translators and i18n people are more likely to
be subscribed there and less likely to be subscribed here.
I didn't do that on purpose because the documentation of i18n shows that
the people who are currently writing those docs don't care too much
about actually building packages. I might ask them to review my wiki
page once it is finished.
xgettext comes with a ton of options to help you. Have a look at the
diff I've attached for what I've been able to do.
Will do and take your suggestions. But it is still a wrapper needed.
Note that you shouldn't define the plural stuff in the POT file, that's
something that's set on a per-language basis. There should also be a
newline between the header and first message block.
Noted.
I have seen this being done in debian/rules' clean target which, in
in-tree builds, causes the POT file to be changed as well and I don't
understand at which step of the packaging process it would be a good
idea to commit that POT file. If I build my package out of tree (like I
do out of tradition of svn-buildpackage, I have gbp configured to use
../build-area), the POT file ends up newly generated in the source
package but never gets updated in git. Adduser had POT files from 2022
in git until just recently because I just never noticed. There is no
lintian check and no check inside tracker.d.o for this.
In other packages, there is a dedicated m4 macro to call xgettext which
doesn't make things easier to understand.
Usually, all this stuff with generating and updating POT & PO files is
upstream's responsibility to deal with, hence why you'll find little
documentation for translating anything other than debconf templates.
The mechanism and the pain seems similar to identical. Text => POT =>
PO.
Since this
is a native package, it's up to you to do what you want. My suggestion is to
run this script before release; the most important thing is that it is run
after the program's messages are updated and _finalised_, and before sending it
to translators.
Is it really the right thing to do that in debian/rules clean target? I
don't expect anything to change during that step that I am supposed to
commit, and it does it step in a place that is discarded after build
when doing an out of tree build.
I think that _this_ philosophy belongs in debian-devel, and I am quite
surprised that noone has an opinion about that.
(4)
Then,
msgmerge --update --backup=none --no-fuzzy-matching "${PO_FILE}" "${POT_FILE}"
is called for every existing PO file. This doesn't move the header from
the POT file to the existing PO file so stupidities like "# COPYRIGHT
THE PACKAGE CREATOR" just never get fixed because the translators don't
seem to care.
The header is only touched when the translation is initially created.
I am not sure whether this is good.
I've rarely seen anyone being condemned for fuzzy translations (but then
again, I work in a language team that has virtually no members).
That was an exaggeration. But I have experienced an instance where
somebody helping me called it "unfriendly" to not manually unfuzzy all
translations after fixing a punctuation issue.
In which stage of package build do I do
msgmerge? Do I commit the merged po files, when do I commit them, what
do I do with them during git merge when a feature branch is merged?
In your position, I would leave the translations and the POT file
untouched on the feature branch, and only ever update them on the main
branch after merging.
That doesn't happen when you work on a feature branch and do in-tree
builds. One would have to be careful to NOT commit those changed files,
and people routinely using git add -a (not me) are going to have commits
of relevant changes to their code/packaging and irrelevant changes to
POT/PO files in the same commit.
Yes, in theory, but it's still helpful to attach it for a variety of
reasons e.g. the existing translation is an old garbled mess and
starting new is the best option.
So podebconf-report-po should have an option to include the POT file
even when asking for individual translations?
(6)
Depending on the age of the existing translations, about half of the
messages I send to individual translators are going to bounce. Am I
supposed to report that to debian-i18n@l.d.o as a followup to the
general translation request so that new translators can take up the
outdated translatorless translations? Or am I supposed to send the
general translation request to debian-i18n last so that I can explicitly
mention the translatorless languages there?
According to the manual page (and from what I've seen on
debian-l10n-ar@l.d.o), the language team listed in the PO file (which
should _always_ be debian-l10n-LANG@l.d.o) is Cc'ed by default, so they
will deal with inactive translators. Anyone working on translations
should be subscribed to the list for the relevant language, so it'll be
picked up. You don't need to do anything extra.
There are languages that don't use the debian-l10n-LANG mailing list (or
the translator didn't care to put in the correct Team address). I am
seeig this for Danish, Basque, Japanese, Korean, Norwegian Bokmal,
Portuguese, Brazilian Portuguese, Slovakian, Ukrainian, and Simplified
Chinese.
Am I supposed to fix those headers in the po file myself? Am I supposed
to ask the translator to fix the headers? Or am I supposed to just
ignore all of that and just accept whatever I get sent? I often feel
like a smart-mouthed know-it-all when I ask a translator to improve the
headers of their PO file.
What you do is up to you. Translation headers are annoyingly
inconsistent from a QA perspective, so don't feel bad for asking
translators to fix headers (or fix them yourself if it's easy enough).
I've had to do this for when I recieved translations for miniflux's
debconf templates.
So it is okay to fix headers in translations?
Sadly, I have some translations that have things like "Copyright SPI" or
"Copyright FSF" in their header, and _that_ is not easily removed.
(9)
I then commit the po file the translator sent me to version control
(10)
And then I eventually release the package.
In theory, it would probably be good to do all that regeneration when
preparing a package for release. Why don't we have a debian/rules target
like debian/rules prepare-release that might be useful for that? How
could we protect us against uploading a package with outdated POT/PO
files? People make mistakes.
I've attached a rough check script in the same diff that tells you if
you're POT is outdated, based on exit code. You could use this in a
pre-commit hook or somewhere in d/rules to fail the build (like
execute_before_dh_auto_configure).
Sounds good. But, how does the build process distinguish whether I am
building for testing, on a feature branch, or for a release? That all
ends up with a human having to remember what to do when building for a
upload.
How am I supposed to handle the unavoidable differences between git
branches, that are probably easier to solve when I am just merging a
feature branch but can be a major pain when merging suite branches like
experimental, stable, unstable where translation work has already been
done?
Wouldn't an "theirs" merge strategy for only the translations work?
During a merge conflict, you can use `git checkout --theirs -- po/`, or
use .gitattributes with `po/* merge=theirs` (I haven't tried this).
This way new translations from, for instance, debian/experimental, will
replace the old ones in debian/unstable.
Merge strategies are a mystery to me, worsened by the fact that they
work a bit (but not completely) the other way arouse when rebasing.
But honestly, if some changes are in debian/experimental or in a feature
branch, the translations should really be left alone, since noone will
use it anyway and the package is prone to further changes.
I'd love to have automated tool support for that.
Thanks for reading up to this point. Writing this message alone has cost
me three hours of my time that I'd rather have put in productive
packaging work, and a sleepless night. You know, when I blow a fuse, I
rant, and then I start writing docs. I guess when I put the result of
this discussion in a wiki page, it should be under i18n, right? I am
inclined to put on https://wiki.debian.org/I18n a dedicated chapter
titled "for package maintainers", probably between "Keyboard input
infrastructure support" and "Meetings" as this is a matter beyond
interna of the translation teams and the i18n effort. Am I on the
correct track with that?
IMO this information should probably go on i18n.d.o.
That page only has a list of languages and links to the respective
coordination pages. And it also links to wiki.d.o/I18n, and that is a
page that I can change.
If you don't want to deal with translation stuff, I'm happy to help with
that aspect, and if you'd like you can offload that on me.
Thank you for that offer. I need to understand things to be comfortable
with tem. I think I am on a good way.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
