BI Publisher: An alternative approach to translations

To XLIFF or not to...

Due to internationalization of businesses and the business processes for which BI Publisher is used, more and more templates need translation. Translation for BI Publisher reports is two-fold; we need to translate the XML data (i.e. Reports or the Data Template) and we need to translate the boilerplates (hard-coded texts) on the template. Step 1 is easy, based on the language you want to create the report in, you can select data in a specific language from the "_tl" tables or "_vl" views. Given the fact that you have installed the language you want to translate to. For the hard-coded texts, prompts and the boilerplates the job is a bit more complex.

How to work with XLIFF
BI Publisher supports translation with the eXtensible Localization Interchange File Format (XLIFF for short). XLIFF is an XML-based format that contains translations. The procedure for using this in E-Business Suite is simple: you let BI Publisher extract the hard-coded texts that are to be translated into an XLIFF file. Then you let the translation agency (or yourself if you like) fill in the translations. This XLIFF file is then used as some kind of search and replace resource; during translation single words and even whole sentences are searched and replaced. The good thing about this concept is that it is fully integrated in the BI Publisher engine and the E-Business Suite setup. This makes it easy to setup. However, maintainance is required each time you change your template; each change in the boilerplates requires you to update the XLIFF file. If you lack to do this, there is a big chance the search and replace won't work anymore. XLIFF translation files are template specific, each word or sentence is translated for one template only. This is unfortunate as a change in grammar rules in a language will require you to adapt all XLIFF files for all templates that translate to that language. Also, the maintainer of the translations needs to be someone with knowledge about XML or XLIFF. As XLIFF is not easlily understood by someone with only a functional view on BI Publisher. More on XLIFF: see XLIFF on wikipedia

The alternative - use E-Business Suite Messages
What alternatives to XLIFF are there? I personally do not like to redo the XLIFF file after each (textual) template change and I want the customer to be able to maintain their own translations. The solution I have implemented at several customers now, leaves the terrain of XLIFF files and uses the E-Business Suite's messages to create and maintain translations. This is how it works:

1. Create messages for all hard-coded texts in each language you want to translate to. Give them a general name like XXCUS_TEMPLATE%
   
2. Add query to the data layer to select the messages for the language the report needs to be generated for (select message_name, message_text from fnd_new_messages where language_code = 'NL' and message_name like 'XXCUS_TEMPLATE%').
   
3. Add form fields. In the layout-template replace each hard-coded text for an XPath statement to pick up a message from the XML (./LIST_G_MESSAGE/G_MESSAGE[MESSAGE_NAME='XXKB_CUSTOMER_NAME'] where XXKB_CUSTOMER_NAME is the message name).
   

The good things about this solution is that the customer can easilly maintain the messages from the E-Business Suite screens. There is no re-generation of XLIFF files when the template layout changes. And for the common prompts, messages can be setup for multiple templates at once; simply use these messages on multiple templates. The drawback of this solution is that all the translation texts will be in the XML data. If you are generating a batch of documents in multiple languages then the messages will be in the batch XML multiple times. I have choosen for this solution, because the alternative slows the performance; when the messages are inserted in the XML just under the root instead of under the reporting element. This will require the BI Publisher engine to switch context from a lower level XML group to the root level mutiple times, and this takes additional time. I believe it is better to have a bigger XML file then a slow performing report.

Conclusion - When to use which?
Probably the best answer here is -- it depends. If you wish to create translation for a steady well-developed template, that is not likely to change and you need only 1 translation it is probably save to choose for the XLIFF solution. On the other hand, if you have several translations for muliple templates and both template and translations will be bound to be changed for several times it is best to go for the message solution as it will save you a lot of maintenance overhead.