Selon Denis Barbier <barbier(a)linuxfr.org>:
> 1.- po4a-gettextize stopped at <jobtitle>
> <jobtitle>Professeur de sciences physiques</jobtitle>
> (I have included it under "translate" in my local version)
> and later at <city>
> (also under "translate", you know some city names must be
translated).
Hmmm, we should definitely check the full DocBook supported tags.
Martin, do you have some time? Otherwise I'll do it.
Consider me out of the picture until the end of the assistant lecturer
recruiting period in France, by end June. Sorry about that.
> 2.- I'm not a/the developer, but maybe a better approach
would be a
> default "translate" for all tags that are not known. It's better
> than failing, I'm afraid, and I don't see any harm in it.
That's appleaing, but I prefere to see the problem than hiding them that way.
The best solution would be that you modify the Sgml.pm file to fit your needs. I
would mainly consist in adding missing tags in the right categories. The rest
should not need to be changed, but if you see any improvement, please inform us.
Then, send us the result for inclusion, so that your work can benefit to next ones.
> 3.- Also the constrain that both files have exactly the same
structure
> is a real problem. I have a tendency to improve the tagging with
> <acronym>... which is not that important, but how about the
> mark-up for translators, which is normally
> <articleinfo>
> <author>
> ...
> </author>
> <othercredit>
> <firstname>
> ...
> <surname>
> ...
> <contrib>
> Traducción al español
> </contrib>
> ...
First answer: If you *improve* tagging, that's a bug in the original which
should be repported and fixed. That's the best way to fix structure discrepancy.
Po4a-gettextize is a very special tool, it has to guess which
strings
are translations of others, and the only information that can be used
is the document structure. If both documents have an identical
structure, the 1x1 determination of translations is straightforward.
But when they differ, this task may become quite hard, so at the moment
it is better to stop than provide wrong translations.
A diff-like algorithm is planned to continue in case of structure discrepancy
(like in po-debiandoc, if I remember well), but still to do.
When the PO file is created, you can change the structure of the
translated document (search for "addendum" in po4a(7)).
addenda are more adapted for the addition of large chunks of text, such as
sections. For simple tag addition, feel free to add them into the msgstr.
Similarly, you could add a <b> tag to a translation with no harm (that I can
predict).
As po4a-gettextize is performed only once, maybe we did not pay
enough
attention to solve these problems, and focused on po4a-translate which
is much more used. But of course if you are unable to generate your
PO file, this becomes quite critical.
A workaround is to slightly modify your translated document to remove
extra tags, and put them later in addenda when your PO file is generated.
Yes, using po4a-gettextize always imply some sort of butchery on the files to
make their structures match. You may have to remove parts of the original and of
the translation. Do not be affraid to do so. The most important is to manage to
get a po file. Once it's done, you may reintroduce the removed parts. If it's in
the master, you'll get empty translations for them. If it's in translation, you
are free to add them in msgstr OR use the addendum mecanism, depending on the
size of the removed blocks and on what you prefere.
Good luck, Mt.