Re: advice on po/pot/po4a layout etc. [and 1 more messages]
Helge Kreutzmann writes ("Re: advice on po/pot/po4a layout etc."):
> answering at least partially from a translators and package
> maintainers view
Thanks for all the helpful advice. Most of it I will simply take on
board and implement, so I have snipped those parts of this mail. I'll
reply only with the bits I had further questions/comments on.
> On Wed, Sep 12, 2018 at 09:48:56PM +0100, Ian Jackson wrote:
> > Relatedly, how do automatic translation coversge tools (we have those
> > I think?) deal with the variety of different possible layouts ?
>
> Hopefully people with background on our i18n machinery can answer this
> in more detail.
In the absence of an answer I guess I will try to keep the layout as
standard as possible.
> > 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.
> > 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 ?
> 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".)
> > 5. Translation priority
...
> If you annote the initial strings with this information ("the target
> audience of this is a Debian developer / a random user") then I belive
> translation teams can and will handle the priority by themselfs. But
> note that some translator simply like the programm and will translate
> everything irrespective of priority.
Right, see my question above.
> > 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.
> 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.
Ian.
Reply to: