Hi,
Le 2025-03-11 12:03, Marc Haber a écrit :
Especially when one uses version control
Having recently worked on a (not yet mergeable as it depends on another
MR) update of the french translation of devscripts and already bracing
for the incoming pain as it's likely that I will have to rebase and
re-update that work several times until it becomes mergeable, I can
understand your state of mind.
(2)
There is some point in the development process when it is time to ask
for translations. Translators need a POT file which contains all the
translatable strings, and they make a PO file from that which contains
the actual translation.
That's for the initial translation. Once there is a .po they will update
it directly and don't need or use the .pot anymore.
(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.
I'm not sure the --no-fuzzy-matching helps here (see below). Also I note
that msgmerge is not used at all in devscripts packaging, which only
uses po4a instead. Maybe you could look there if it could help your
case.
If a po file for a language already exists during this step, the
already
existing translation gets merged into the new po file. In some
circumstances that I have not understood yet, the translation gets
"fuzzied", which I have been told causes a lot of unnecessary and
repeated work for the translators which I am supposed to avoid by doing
manual work myself which I don't understand. Not doing this work is
condemned as "not being nice to translators".
As was pointed out in another message, "fuzzied" normally means the
source message was slightly modified, e.g. an additional value for an
option was added, but msgmerge was still able to match the original
message location. In this case it means that the translation previous
translation is retained but is now out-of-date. This is actually useful
for translation work, as it makes it possible to locate translation
strings that need to be worked on.
In a few cases there is spurious "fuzzing", e.g. when the source message
uses `...' for quoting where it shoud have been using \"...\". In some
of these cases it may be possible to fix the issue in the source
message, but I believe other cases are actually bugs in msgmerge. Are
these what your translators are asking you to deal with?
In theory, for an already existing package, the POT file is not needed,
right?
It's needed to translate to a new language, and it's nice to have it in
other cases.
They usually don't bother about the header or copyright, so things like
package name, licenseª, Project-ID-Version and PO-Revision-Date are
often questionable, unclear, just plain wrong or cause extra work to
package maintainer because, for example, a different license was chosen
than the actual package is licensed under either out of incompetence or
not caring.
Some dedicated tools (e.g. poedit) automatically update some headers
(including PO-Revision-Date) and make it possible to update other
comments. They also mess up the formatting (e.g. wrapping).
On a merge request I would just post comments to ask the translator to
fix the headers metadata and licensing, but may still deal with
normalizing/rewrapping myself (e.g. by adding a commit to the MR where
possible). If this were exchanged over e-mail I would probably fix most
trivial things myself.
² adduser has strings that get used in both translated and untranslated
form, making sure that messages written to the console are translated
and messages written to syslog are written in English to make handling
bug repors easier
The "industrial" way to deal with in other (usually large) projects is
to pre/postfix all source log messages with a unique identifier e.g.
"(ADDUSER-1234)". This makes it possible to have tech-support-friendly
and end-user-friendly translated log messages, and as an added benefit
it has excellent SEO characteristics when it comes to searching for
workarounds on the web or in a knowledge base.
³ I have received translations that were obviously done against the POT
file from stable.
That's a start, I guess. Maybe in these cases you can keep the .po file
as submitted for proposed updates, merge it in unstable and nicely ask
the translator to also please work on the upcoming version.
Cheers,
--
Julien Plissonneau Duquène
