Hello Ian,
On Mon, Sep 17, 2018 at 03:42:39PM +0100, Ian Jackson wrote:
> Helge Kreutzmann writes ("Re: advice on po/pot/po4a layout etc."):
> > On Wed, Sep 12, 2018 at 09:48:56PM +0100, Ian Jackson wrote:
> > > 3. I am not sure how to divide up my translation inputs (pot files).
> ...
> > From a translators POV try to avoid too many pot files. Usually
> > translation teams are understaffed, so if you really must split the
> > files, do so by importance and label the "level 1", "level 2" or "prio
> > 1" and "prio 2". This will guide translators. But if you want
> > consistency, have a few (or even a single file) might be best.
>
> I think this means I should have one .pot file for all the messages.
Yes. This ensures consistency for translators. And as messages are
usually rather short, size doesn't matter here too much.
> > > The git-debrebse package has its own data model and conceptual model,
> > > and its documentation is carefully written to talk about that in the
> > > right terms. Additionally, perhaps it is useful for a translator to
> > > know whether a string they are translating is part of a reference
> > > manual or a tutorial.
> >
> > Giving context information to translators is always good. You can add
> > annotations via po4a, so guiding translators is appreciated.
>
> That sounds very useful but I didn't find that feature. I have looked
> in po4a(7) and po4a(1p). Can you point to an example where this has
> been done, and/or some reference documentation ?
Ok, it works for Debconf and plain PO files, see e.g. gdm3 (grep for
"Translators:").
I admit I've never used it for po4a, though it should be possible,
looking at Locale::Po4a::Po(3pm)
→ Functions to build a message catalog
→ automatic
It appears as if po4a.gettextize does not (yet?) support this. You
might want to check this with the po4a authors (its worth at least a
wishlist bug).
An alternative would be to post process the po(t) files, we do this
for the German man pages (cf. toddy / Tobias Quadthammer or the
scripts in sources of manpages-de for details).
Then you could manually insert a paragraph or a table (as comments,
before the first
msgid ""
msgstr ""
E.g like
# Translation of prog documentation to LANGUAGE
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the prog package.
#
# Translators:
# Some explanation for translators
#
# Translator Name <email@adress.org>, YEAR.
msgid ""
msgstr ""
The first 4 lines you would leave untouched in the translation, as
well as all lines directly before the msgid line (there could be
several translators over time).
If you have an online document, you could point translators to it.
> > Try to avoid duplicating strings, this is really bad for translators.
> > Splitting translations might make sense, as it is usually much larger.
> > If a translator encounters a 100 string file for an important tool,
> > (s)he might start and finish much quicker (including review on the
> > translation list) than say for a 500 string file.
>
> Right. (I take it that when you say "Splitting translations might
> make sense", by "translations" you mean "translation of documents" as
> opposed to "translation of messages".)
Correct.
> > > 6. Committing the .pot file
> ...
> > > That seems odd. What is the reason for this ? Can I sensibly diverge
> > > from this and expect translators etc. to run a build rune to get the
> > > .pot files ?
> >
> > Please don't. [...]
>
> OK. In which context...
>
> Jacob Sparre Andersen writes ("Re: advice on po/pot/po4a layout etc."):
> > You can't expect translators to be ready to run any commands (or even to
> > have the required tools installed) to generate the .pot file(s).
>
> This implies that I must commit the file.
Correct.
> > But it is still (in my opinion) a bad idea to commit the .pot file. You
> > should rather include it with other build output, and make sure it is
> > archived in an easy-to-find location for your translators, so they don't
> > have to figure out how to build the program (or just the .pot file)
> > before they can start translating.
>
> I'm not sure what you mean by it being a bad idea to commit it but
> that I should include it with other build outputs.
>
> Build outputs go in the binary package. They do not appear in my
> source. That is, they appear neither in my git repo, nor in the .dsc
> source package.
>
> (And git and the source package will be identical; I don't believe the
> notion of some kind of intermediate source makes any kind of sense.
> The Debian archive is a VCS - just a really really bad one.)
>
> You both say the translators don't want to run `make' (or the
> equivalent) to make the .pots. I obviously don't want to ship the
> .pots in my .debs. Therefore the .pots must be in the source.
>
> So I will do that. There is already one other autogenerated file in
> the source, debian/tests/control.
I was a little imprecise, sorry.
What I intended to state:
Please carry the pot file in your sources. Update it whenever you feel
necessary, but at least before a release, so that the tar ball
contains an up to date pot. The pot file should not be part of the deb
package, of course.
It is a good idea for old school translators like me to have a brief
description how to update the pot and po files in your source, like
make update-po
so when translators decide to work directly off your repository, they
know how to create an up to date pot file.
Greetings
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature