Javier Fernández-Sanguino Peña <jfs@computer.org> (21/12/2005):
> On Wed, Dec 21, 2005 at 12:28:15PM +0100, Thomas Huriaux wrote:
> >
> > IMO, that's not the best approach. If the upstream maintainer does not
> > want to use po4a, we should find a way to use po4a in parallel, i.e.
> > having the translators working only on po files and sending the
> > regenerated documents upstream. We should definitely try to drop these
> > unfriendly formats for translators.
>
> I don't like to use po for documentation. Translators lose context and that
> sometimes mean worst translators. That being said, I'm probably not alone and
> that means that, even if po4a is available, it should not be forced down
> every translator's throat.
I confirm that you are not alone. But I don't understand this context
problem. When I translate a program, I check where the strings in the po
appear in the program. If I translate a po-debconf, I use some tools such
as podebconf-display-po to understand when and how the strings I have
translated appear. This is because I can't (I think like everybody)
figure out what a single string really means out of its context. The
same thing applies for the documentation: if I translate a manpage or
an sgml document, I will have to convert it into a "human" format, and
check if my
"<ul><li>foo<ul><li>bar1</li><li><strong>bar2</strong></li></ul></li></ul>"
is what I understood when I was translating this file.
The context problem may be a little bit worse with po files than with
initial files, but you still have to go through the proofreading step.
And you already have this problem with the current po files, i.e.
program translation and po-debconf for example.
> > The goal is therefore more to create the infrastructure to handle this
> > situation than to try to keep these formats and work with them.
>
> We have some formats that will never be converted to po4a (like wml)
"formats that will never be converted" or "formats that we will never
be able to convert"?
There is an under-development module for wml.
> so we should consider those (and more to come). Being flexible (and
> not forcing everybody to use your pet tool) is a better way to have
> translator teams integrate into a common tool. If you don't do it that
> way you'll end up having some i18n tools use different tools because
> they are not comfortable with the ones being forced upon them.
I don't force anybody to use "my pet tool", I just think that the po
format (using xgettext, xml2pot, po4a or whatever) is the best interface
for translators. After this, you are free to use the tools you want. I
think that having the common following interface for every format is
the best way to be flexible:
conversion tool translation tool
original file <--------------> po file <----------------> translator
With this, package maintainers are free to use the format/tools they
want (xml with xml2pot, sgml with po4a, ...); translation teams are free
to use the translation tools they want (text editors, pootle, mail
interfaces, ...).
Cheers,
--
Thomas Huriaux
Attachment:
signature.asc
Description: Digital signature