next »

[mcc]

So maybe I'll make a longer post about my Adventures In Localization later, but here's just a short question for now.

I was looking at Apple's localization stuff, and saw in the docs that some of their tools accept translations in a format called XLIFF. I looked this up and this is apparently supposed to be some kind of standard XML container for holding translation data. It looks like this is a huge deal in Java/C# land (and I saw claims in a few places Flash works with it natively?) and there are supposed to be all sorts of standard tools for working with it. Well, great, I thought.

Except...

Looking around, I couldn't quite seem to work out how I'd integrate it into a project. It seemed a little too tied to Java-land-- there didn't seem to be any C++ libraries for working with it, and most of the gui tools are written using Java (read: they have painful UI). There are no native mac tools at all (there's an out of date project that doesn't work with snow leopard). And like everything that exists at the interface of Java and XML, it seems just a little overengineered. It's got these fascinating  features (things like tracking the translator for each individual line, or storing version information so that you can use one file across multiple build versions of a project) but the feature set is so rich it sort of looks like most tools aren't going to support the whole standard. Like, one of the features is storing multiple language translations in a single file, something that sounds really attractive to me, but apparently most of the tools don't work with that feature.

I'm curious. Does anyone work with this XLIFF thing? Are there real benefits to using it, is there some sort of killer tool that makes it worth it to use it? Or will trying to work with this thing just create more work than it saves?

( I didn't ultimately use it, I wound up just dumping my strings+translations into one long text file with minimal formatting, so that I can just run it through a perl script later if I need it converted to other formats. But I guess that means I could convert it to XLIFF if I needed to :P )

[Triplefox]

I've never heard of XLIFF but from your description it sounds like a lot of "corporate" software projects - big, ambitious, doesn't do anything as advertised, yet somehow it is supposedly used in "Real Enterprise Systems." It's very common to come across these sorts of projects in the Java and MS ecosystems.

<Reads spec>

I was right. It's underspecified for real use-cases - no coherent model for implementation emerges naturally from the spec, other than "grab the fields you plan to use and ignore the rest" - and it has a ridiculous kitchen sink of optional fields that, in some ideal fantasy land, XLIFF producers and consumers would all support. Then they mention "oh, it's extensible just in case." Which means everyone is going to go and break the spec to get shit done.

The only way such a bloated spec could ever get traction is if someone like Adobe put together a massive app for doing translation work, one that substantially improved the process, and made XLIFF the primary export format. Apple might have picked it up because someone in the company's engineering staff pitched a fit about standards, but I can't imagine they're making much use of it themselves.

If you want to see working examples of game localization, try looking at what open-source games are doing. For example, Wesnoth has some prolific language support now: http://svn.gna.org/viewcvs/wesnoth/trunk/po/wesnoth/ 

I had no idea what "po" is - took me ages to find that directory - but it appears to be the compiled result of this tool: http://www.poedit.net/ 
Very promising stuff.

[mcc]

Triplefox, that looks really nice. Thanks for the link!

[mcc]

( And to get off topic for a moment, the "grab the fields you plan to use and ignore the rest" thing-- actually it's even funnier than it looks at first: Basically Apple's ibtool can take in translation data in XLIFF format, and use this to generate translated GUI layout files ("nibs"). But it can only use XLIFF files it itself created. It has a flag for generating this highly structured stub translation file, where each window pane has a section and within it each button or label or whatever has an ID that the translation data gets attached to. But if you feed it an XLIFF which is valid but structured in some other way, like as just a set of english string / otherlanguage string pairs, it won't know what to do with it.

So there's a workflow that makes perfect sense here within the context of Apple's tools-- you use ibtool to emit your stub xliff file, you feed it into any of the standard translation editor programs that work with XLIFF, you write out the translation, then you feed the filled-out file back into ibtool and it creates your translated GUI. But it sorta seems like the point of there being something like a standardized container format for translation data was lost here at some point? Meanwhile in addition to xliff ibtool also takes its own internal format-- which is not only easier to parse and generate, but also seems a little bit less brittle, which means it's probably what I'll actually wind up using :/ )

[RyanTon]

Whoa, I'm really late at this party. With the risk of waking up Smaug, if anyone's still looking for a tool to edit XLIFF files (and I expect many would be), check out https://poeditor.com. It has plenty of cool (and useful!) features, it's freemium and can be used to translate strings collaboratively.
Here's a little guide to using this tool with XLIFF: https://poeditor.com/help/how_to_translate_ios_xliff