Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
feature request[Openbravo ERP] F. LocalizationmajorN/A2009-01-19 16:442009-02-03 11:04
ReportergforcadaView Statuspublic 
Assigned Tormorley 
PrioritynormalResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0007007: Use XLIFF format to output the translations files instead of a custom xml file

DescriptionRight 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.
Proposed SolutionTo 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] [^]
TagsReleaseCandidate, translation
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
jordimas (reporter)
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.

pjuvara (reporter)
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.
gforcada (reporter)
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] [^]

- Issue History
Date Modified Username Field Change
2009-01-19 16:44 gforcada New Issue
2009-01-19 16:44 gforcada Assigned To => rafaroda
2009-01-19 16:44 gforcada sf_bug_id 0 => 2520119
2009-01-20 17:36 jordimas Note Added: 0012405
2009-01-20 17:36 jordimas Issue Monitored: jordimas
2009-01-21 09:16 rafaroda Assigned To rafaroda => pjuvara
2009-01-21 22:26 pjuvara Note Added: 0012491
2009-01-21 22:26 pjuvara Status new => feedback
2009-01-23 13:14 gforcada Note Added: 0012567
2009-02-03 11:04 pjuvara Assigned To pjuvara => rmorley
2009-02-03 11:04 pjuvara Status feedback => new
2009-02-03 11:04 pjuvara Status new => acknowledged
2009-02-03 11:05 pjuvara Tag Attached: ReleaseCandidate
2009-02-26 12:35 rmorley Tag Attached: translation

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker