Re: PO-based Documentation Translation

[Tim Foster <Tim Foster Sun COM>]

hi there,

Yes, I agree with the simplicity of the .po format : that's certainly
it's strength. Unfortunately, it's also it's greatest weakness (God,
that was dramatic, wasn't it!? ;-)

The trouble is that with .po files, down the line you have to start
hacking the format with custom extensions when you decide you want to
help the translator out by adding things like fuzzy matches, machine
translation hits, glossary items and other aids to translation.

I know, because we had *exactly* that problem in Sun. Here's the sort of
po file we were starting to generate (disclaimer: I don't speak French!)
# this is a message used by main.c
# @LC_COMMENT@ This is a special comment for localisers
# @LC_FUZZY@ This is a big message
# @LC_FUZZY_TRANS@ Voici une grande message
# @LC_MACHINE_TRANS@
# @LC_GLOSSARY@ [1] message
# @LC_GLOSSARY_DESC@ [1] n. a packet of information
# @LC_GLOSSARY_TRANS@ [1] message
msgid "This is a message"
msgstr "Voici une message"

Now, when you get a po file that's broken, or has a misspelt @LC_XXX@
directive or is missing a ", you're screwed, unless you've hacked the po
parser to detect these sorts of things. I guess the same arguments can
be aimed at XLIFF, just that validating xliff can be done by any xml
parser out there and is less work...

Before you know it, you've re-implemented XLIFF, and have actually made
the process more complicated for everyone involved since yours are the
only tools that can make sense of the format.

I appreciate that making things a little more complex for new
translators to start translating GNOME is a big minus point[1], but at
the same time, you're also increasing efficiency of existing
translators.

All sorts of other goodies become available at this point (in
particular, you can start writing code to get translation matches across
both docs and software, thus improving the quality and consistency of
the translation to the end user)

Finally, for what it's worth, I've taken a document from the GNOME 2.4
user guide, and passed it through our tools. (We have the 2.2 user guide
in our translation memory already) A screenshot of editing :

http://www.netsoc.ucd.ie/~timf/gosoverview.xml

in our editor can be seen at

http://www.netsoc.ucd.ie/~timf/Screenshot-TransEditor.png

None of the translation memory lookup gets done using this tool, it's
purely for translators - all the backend stuff is done on a J2EE server.

Hope this helps outline more clearly the problems we had in the past and
our reasons for migrating to XLIFF.

	cheers,
			tim

[1] I would argue that it makes things easier, because they're given an
easy to use translation application that hides the complexity of the
underlying format. For example, we protect inline tags like <emphasis>
from editing, we can ensure that all the tags that appear in the source
segment appear in the target segment, we can allow translators to see
previous translations of that segment, etc.



On Sun, 2003-09-28 at 11:24, Christian Rose wrote:
> fre 2003-09-26 klockan 15.16 skrev Tim Foster:
> > I've mentioned this before[1] : we've an article on the advantages of
> > XLIFF at
> > 
> > http://developers.sun.com/dev/gadc/technicalpublications/articles/xliff.html
> > 
> > (there's an interesting screenshot on that page of an editing
> > application that I believe could be useful to the GNOME community :
> > since it edits XLIFF, you could use the same application to translate
> > files converted from po, html, sgml, xml, etc. Fuzzy matches from
> > previously translated material (across all formats) can also be shown in
> > a separate window, with an indication as to where the texts differ)
> > 
> > I apologise for the delay in determining whether these things can
> > released, and in the meantime, if you choose to go down a route other
> > than XLIFF, I can't blame you (since I don't have the power to help out
> > yet)
> > 
> > That said, I would strongly recommend at least considering a format
> > designed from the ground up to support the needs of localisation. XLIFF
> > really does fit the bill here imho. We do have technology to allow
> > translators to translate a range of different source formats in a single
> > unified manner, and I'm dying to see if you'd find it useful.
> 
> The article mentioned above is *very* interesting -- thanks for
> providing that link. To anyone who hasn't read it and is interested in
> this topic, I strongly recommend taking the time to read it.
> 
> It seems XLIFF has several benefits. It
> * Is designed from the ground up with localization in mind
> * Adds many highly useful properties and primitives to messages, that
> are missing from simpler formats like .po
> * Is standardized and XML-based which aids machine-based parsing
> 
> On the other hand, it
> * Would add yet another format to the process
> * Adds lot of extra syntax
> * Seems to be much less suited than .po for direct editing and requires
> using a special tool/editor for the format to be really useful and not
> get in the way
> 
> I think the last points are very important from a GTP perspective. In
> general we want the barriers for entry in aiding the GNOME Translation
> Project to be as low as possible, so as to attract as many contributors,
> and as a consequence, translations, as possible.
> The simplicity of the po format is a great benefit in this regard. The
> syntax is simple and reduced to a minimum and it doesn't really require
> a specialized editor, but can be edited by hand in an ordinary text
> editor. In fact, it seems that many of the current translators do work
> this way when editing the translations.
> In theory, one could even fetch the translation from the web, edit it in
> Notepad on a Windows machine, and send it to someone with cvs access
> without ever using a specialized tool of any kind, or feeling a strong
> need to do so.
> 
> That being said, it seems XLIFF would have its uses, in particular for
> behind-the-scenes processing like, as an example, a backend format for
> translation memory tools and the like. But I don't think it's a format
> that we would like to directly expose volunteer translators to.
> 
> 
> Christian
> 
> 
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n gnome org
> http://lists.gnome.org/mailman/listinfo/gnome-i18n