On Wed, Mar 12, 2025 at 11:36:27AM +0100, Julien Plissonneau Duquène wrote:
Le 2025-03-11 12:03, Marc Haber a écrit :
(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.
So all love I put into the POTs header will go unnoticed and I'll need
to pay attention to individual translations' header until somebody else
cares.
(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).
Since --no-fuzzy-matching is just superficially documented, ...
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.
po4a seems to try to do those things automatically, using msgmerge as a
subprocess.
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?
Not directly the translators, but many years ago somebody who helped me
with making a package fit for translation mentioned that such changes
are unfriendly to translators and that one should handle those manually
and unfuzz things (in a manual process that seemed clumsy and
error-prone to me even back then).
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.
So you're saying that as package maintainer I can freely edit headers
and metadata for translations, putting the PO file into a mixed domain
between package maintainer and the respective translator?
² 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.
Yes, I'd rather not do that because my inner monk would first cause me
spending a few days to catalogize and abstract adduser's messages. Time
that I'd rahter not spend at the moment.
³ 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.
But translating a stable package does show a blatant non-understanding
of Debian's development mechanisms! How am I supposed to trust people
who care THIS little about the project they're contributing to?
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
