Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0007007Openbravo ERPF. Localizationpublic2009-01-19 16:442009-02-03 11:04
0007007: Use XLIFF format to output the translations files instead of a custom xml file
Right now, when you export a translation if creates several xml files which aren't following any industry standard because they are a custom version (don't know if it's inherited from Compiere).

The main problem with a custom xml file format is that localisation is not just marking strings as translatable, extract them to a file, get them translated and send back to the application.

Translating is really complex, there are translation tools, lots of other formats, professional tools, assistive technologies, translation memories, translation guidelines, compendiums and so on that makes translating Openbravo ERP more complex than it should be.
To nail down this big issue within the translation front it would be enough with just changing the output format used by Openbravo ERP to XLIFF[1].

Then there won't be any need to have tools like Openbravo2PO[2] and specific translation guidelines[3] for Openbravo ERP, since there are lots of XLIFF tools out there and converters to po file formats, which is the standard in free and open source software i18n.

[1] [^]
[2] [^]
[3] [^]
ReleaseCandidate, translation
Issue History
2009-01-19 16:44gforcadaNew Issue
2009-01-19 16:44gforcadaAssigned To => rafaroda
2009-01-19 16:44gforcadasf_bug_id0 => 2520119
2009-01-20 17:36jordimasNote Added: 0012405
2009-01-20 17:36jordimasIssue Monitored: jordimas
2009-01-21 09:16rafarodaAssigned Torafaroda => pjuvara
2009-01-21 22:26pjuvaraNote Added: 0012491
2009-01-21 22:26pjuvaraStatusnew => feedback
2009-01-23 13:14gforcadaNote Added: 0012567
2009-02-03 11:04pjuvaraAssigned Topjuvara => rmorley
2009-02-03 11:04pjuvaraStatusfeedback => new
2009-02-03 11:04pjuvaraStatusnew => acknowledged
2009-02-03 11:05pjuvaraTag Attached: ReleaseCandidate
2009-02-26 12:35rmorleyTag Attached: translation

2009-01-20 17:36   

Well, XML is an industry standard :)

I think that we should explain better:

· The shortcomings of the current Openbravo XML format. Which fields are we currently missing and how we will use them if present. Please, put an example of each shortcoming.

· How XLIFF solves these shortcomings

· The benefits of XLIFF compared to our current format

Thanks Gil, this feedback is very useful.

2009-01-21 22:26   

thanks for the suggestion. As you know translation is a pain point and any idea on how to improve it is more than welcome.

Can you please provide the additional information that Jordi is asking for? Those would be very helpful in assessing the benefits of switching to XLIFF.
2009-01-23 13:14   
== The major shortcomings are: ==
- There is only a flag per <row> instead of a flag per <value>:
<row id="1005800001" trl="Y">
  <value column="Name" original="Heartbeat">Heartbeat</value>
  <value column="Description" original="Heartbeat pop-up window">Heartbeat pop-up window</value>

With this, both <value column="Name"> and <value column="Description"> are assumed as being translated. For column="Name" is fine, but not for column="Description"

This is somewhat fixed in openbravo2po-valuetrl[1] but it has some major bugs[2].

- Is an error prone format:
Since it was designed in the Compiere times there isn't an easy way to mark a translation as "To be reviewed".
There is not an easy way to pre-fill a translation based on a translation memory.
There is not an easy way to use a glossary for consistent translations.

- There is no easy way to use and reuse translation memories:
You are forced to translate a plain xml file, which is a pain, or convert to po files which are ok, but it is not an industry standard and has lots of shortcomings (strings status, translation memory, glossary ...).

- There are few capable editors:
Mostly lokalize (former kbabel), gtranslator (which is expected to have a 2.0 release soon) and some on-line translation tools.

== How XLIFF solves these shortcomings ==

XLIFF is a file format designed for translation management, with TMX [3] (translation memory) and TBX [4] (terminology) any professional translator, or an enthusiast translator, doesn't need anything more.

All matches (strings that are the same in different files) will be translated once, hence, the translation process will be less tedious and the overall translation will be a lot more coherent since all matches will be translated equally, leaving the choice to translate one different if needed (if "make" for example is a verb or a noun it can be translated different in some languages).

There are lots of translator editors, from command-line, typical GUI desktop tools and on-line translation systems that can handle XLIFF files.

== The benefits of XLIFF compared to our current format ==

The major benefit is that with tools (see Programs section below) like Pootle everything tried to achieve with Openbravo2PO, and more tools that should be build can be done with a single instance of Pootle. The workflow would be less painful if Openbravo ERP outputs its translations as XLIFF since no file format converters will be used (= less chances to mess something). Major programs such as or Mozilla are using Pootle for their translation workflow. Even it could be added as a plugin in the Forge and allow project admins to mark their projects as translatable!

The Pootle approach doesn't means that everyone is forced to translate with Pootle, you can download up-to-date XLIFF files from Pootle and translate them with your preferred tool (see Programs section below).

Obviously we aren't forced to even use Pootle and fix to handle xliff files to display statistics and provide up-to-date XLIFF files. should have been a couple of months of defining the uses, coding, reviewing and releasing if we had been using XLIFF. Since it was not the case Phil, had to work (a lot) on improving Openbravo2PO for the new requirements. If we had been using XLIFF by those days, the process would not had expanded for so long since all the needed tools (updating xliff files, calculating their statistics...) were already done and they are used by several projects and thus are usable (i.e. no bugs or major blockers for our needs).

== Programs ==
Open Language tools (Utilities and editor): [^]

Translate toolkit (Converters and utilities): [^]

Pootle (On-line translation tool): [^]

Xliff-tools [^]

Sowrdfish (XLIFF translator): [^]

Stingray (TMX editor): [^]

Xlfedit (XLIFF editor): [^]

There are even more, some of them just professional and paid only tools, obviously oriented ad translation companies that do wonders with XLIFF, TMX and TBX.

== Major XLIFF supporters (companies and other associations) ==
Localisation Research Centre[*]
Red Hat
SDL International[*,+]
US Department of Defense
University of California, Berkeley

[*] Localisation firms
[+] Major translation companies, see:

- [^]
- [^]

Source: [^]

== References ==
[1] [^]
[2] [^]
[3] [^]
[4] [^]