Translation equation: Is your global BI speaking the same language?

When it comes to global BI, language differences can threaten user adoption and ROI if not handled correctly, writes BI expert Patrick Leonard.

Sustained success for any business intelligence (BI) project depends on user adoption, be it a result of hard-to-access content, poor data quality, useless reports, or unappealing visualizations. In the case of global BI deployments, user adoption and usage depends on everyone having access to the same content, despite language differences among the different operating countries. That barrier can be avoided, thanks to the SAP Translation Management Tool (formerly SAP Translation Manager.) It is a wonderful tool for supporting global BI deployment of SAP BusinessObjects content in a variety of languages, and you only need to maintain one base version of collateral in such applications as Web intelligence reports, dashboards and universes.

Both the Translation Management Tool and SAP BusinessObjects employ the concept of a locale for delivering tailored content to users. A locale is the user's viewing environment defined in terms of their region and language. For example, mine is "en_US" -- meaning I wish to receive content in English, with the regional formatting associated with the United States -- while a French-speaking user would have "fr_FR".

Regional formatting pertains to items such as currency punctuation ("2.50" vs. "2.50") and date displays (July 1, 2013 as "7/1/13" or "1/7/13"). While the date and currency changes are primarily handled on the platform side of BusinessObjects based in the user's Preferred Viewing Locale rather than in the Translation Management Tool, it is important to keep the changes to your BI content in mind in case users end up with a different experience than intended. Locales can be set according to either the browser used to access the content or the specific user. You can do this in the launch pad preferences in 4.x versions of BusinessObjects.

For more on SAP BI

Is SAP Lumira worth a look?

How does SAP BI stack up against the competition?

Learn how stack integration advantages spur BOBJ adoption

In a recent SAP BusinessObjects BI project, a leading utility services company needed to build BI collateral to provide customer service-related content, as well as detailed analytics on data consisting of dozens of highly tailored dashboards and many pre-designed Web intelligence reports. This content was packaged to be made available to utility companies so they could better serve their consumers. The material had to be delivered in the language of any potential customer across the globe.

The utility was able to develop one version of the content but leverage the translation management tool and the rest of the BusinessObjects platform to meet its translation requirements with minimal hassle and development expense, especially since the tool allows for the use of third-party translation methods. Because the company was marketing the content, the ability to deliver in multiple languages made this much more than a BI initiative. The absence of appropriate content could very well preclude the company from getting in the door with potential customers and, as a result, leaving market share and revenue on the table.

One of the first steps in translating BusinessObjects content should be determining if the translation work will be done internally or through a third party. The Translation Management Tool can export the structure of the content -- be it a report, dashboard or other item -- in an XML-based file referred to as XLIFF (for OASIS XML Localisation Interchange File Format) that can be used by many professional translators and imported into the document with the translations that are to be published to the BusinessObjects Enterprise (BOE) repository. If the translations are to be performed in house, the Translation Management Tool provides that ability within the client.

In addition to an intuitive method for users to input translations, there is also a helpful validation process that provides status indicators, such as "Needs Review" and "Needs Translation". Regardless of who will be doing the translation, it is important to prepare the content first.

For example, it is important to account for differences in the word lengths of different languages. While doing so is certainly important for reports, it is imperative for dashboards, as they typically have rigid designs. You can go from having a perfectly laid out visualization with everything sized and spaced perfectly, to something that no longer makes sense, with scroll bars all over your once-beautiful canvas (this one may have caught me by surprise once).

Here's an example that shows the steps for doing a quick translation of a Web intelligence report (though this example doesn't apply to Web intelligence universe translation):

1. Create a report from your data set (in this example, the e-Fashion data set).

2. Include a simple table with Store Name, Sales Revenue and Quantity Sold.

A simple table
Step 2

a. Change the header that is automatically created in the report from "Report 1" to "Annual Sales by Store".

i. Remember the issue with =GetLocalized() mentioned earlier and that the formula for this text item will actually need to be "=GetLocalized("Annual Sales by Store")"

b. Change the 3 column headers to "Store", "Amount Sold" and "Number of Items Sold" respectively.

3. Save this report to your repository ("Translation Test 2013" in this example).

Import the document
Step 5

4. Open the Translation Management Tool and connect to your repository, ideally as Administrator if you have that ability.

5. Import the document "From Repository…"

Add languages
Step 6

6. Add the languages you wish to translate the report into from the list in the bottom left.

a. Here, French (France) and Spanish (Mexico) are chosen and made visible.

Input translations
Step 7

7. In the middle area of the tool, input your translations for each individual item shown. You will notice that there are line items for the column titles and header that were added to the report. This is a result of using "GetLocalized()" around the text. Each line is pre-populated in italicised blue font with the same text as the original content language.

Save translations
Step 8

8. Save the translations provided and export the translation data back to the repository so the report in question will be able to access the new translations.

Log back in
Step 9

9. Log back into your BusinessObjects launch pad, change your preferred viewing locale setting to French (France) and navigate to the translated report.

Open the report

Step 10

10. Open the report and notice the translated text throughout.

The Translation Management Tool, while not always the most pleasing program to use due to its bugs, provides a vital resource for many organizations striving to deliver truly globally accessible and relevant BI content. In spite of the ability of the tool to rapidly create localized content, keep in mind that having the right translation staff -- and when going the third-party route with a content-specific dictionary -- is just as important as this tool, especially in highly specialized industries where a word may have a very specific meaning that means something else outside the organization.

An example from the utility deals with the word "volume." In one module, it meant the amount of water consumed by a household in the previous 45 days, yet it was translated by a third-party to refer to the level of sound. Because the developer did not speak the language being translated into, the oversight was not caught until a language-specific tester was brought in weeks later, resulting in additional costs and a nearly missed release deadline.

Keeping an eye on such nuances is exactly what the SAP Translation Management Tool helps organizations to do, as well as keeping projects on schedule without too much hassle.

About the author:
Patrick Leonard is a business intelligence consultant with Atlanta-based Decision First Technologies.

Dig Deeper on SAP business intelligence