[Po4a-devel]Mising tag

[martin.quinson@free.fr]

Selon Denis Barbier <barbier@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 transla=
ted).
>=20
> 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 n=
eeds. 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 inf=
orm 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 structur=
e
> >     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=F3n al espa=F1ol
> > 	    </contrib>
> > 	    ...

First answer: If you *improve* tagging, that's a bug in the original whic=
h
should be repported and fixed. That's the best way to fix structure discr=
epancy.

> 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 discrep=
ancy
(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 a=
s=20
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 generate=
d.

Yes, using po4a-gettextize always imply some sort of butchery on the file=
s 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 man=
age 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 translatio=
n, 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.