Hitachi Vantara Pentaho Community Forums
Results 1 to 2 of 2

Thread: Reports localization into not supported languages

  1. #1

    Default Reports localization into not supported languages

    Hello all.

    I am from Slovakia, I wouldn't be surprised if most of you haven't heard about it.

    However, that causes me a troubles when it comes to reports. We need to have 3 (soon 4) language versions of each report: Slovak is main language, than, Polish and English.

    Since pentaho does not support Polish nor Slovak, it is really pain for me to keep these localized.

    What I do is:
    # Create report in Slovak language
    # Write down all phrases from report
    # Send phrases to one of our partners to translate
    # Create its copy in either pl/en directory
    # Open it in Report Designer and edit every phrase accordingly
    # Save as another language version

    As you can imagine, the process is very time consuming, and error prone. Plus, every time I add new parameter to report or change its data source (which is BeanShell script), I need to do it in 3 separated files. As a result of this, language mutations are usually out of date, way behind main language version.

    I have tried to automate it with OneSky and did a script that does 2 stages:

    Stage 1:
    # Change *.prpt files sufix to *.zip
    # Extract phrases from files: ~/datadefinition.xml, ~/layout.xml, ~/styles.xml, ~/datasources/inline-ds.xml
    # Put those phrases into *.po file
    #Export *.po file into OneSky

    Stage 2:

    # Change *.prpt files sufix to *.zip
    # Download translated *.po file from OneSky
    # Run through ~/datadefinition.xml, ~/layout.xml, ~/styles.xml, ~/datasources/inline-ds.xml files and replace original phrases by translated

    While this aproach works fine, it doe not translate everything. There are still flaws of this process. I need to go through it every time I do even slightest change in data source of report or fix small mistakes. Even if I just do a small six in SQL code, I need to do it in 3 files. That of course increases chance to mistake be made.

    Soo, I was wondering, how are you guys solving this issue with translating of your reports?

  2. #2
    Join Date
    Mar 2003
    Posts
    8,085

    Default

    Use a "resource-message" and/or "resource-label" field for all text outputs. These elements look up the text to print in a resource-bundle (which can be embedded in the prpt itself). The bundle is a iso-8859-1 encoded properties file (basically the standard method used for translating Java based programs). If you create a new report in PRD, then you should already have a "translations.properties" file in that report. Check via "File->Resources..".

    The base / fallback language should be given as "translation.properties", and all translated languages are given as "translation_en.properties" where en is the 2 letter language code for English. If there are multiple incompatible languages (think of English and US-English), then you can qualify this with an additional country code: "translation_en_US.properties" for those non-proper-English speakers ).

    There are some limitations around charts and inline datasources, namely that they do not have translatable properties. However, depending on your programming skills available, you could use a report-pre-processor to search and locate all charts and then let the preprocessor translate the relevant properties by looking them up in the embedded resource bundle.

    Prompts can be translated via the "RESOURCELOOKUP" formula function.

    Inline-datasources are not suitable for translation. Given that most reports work against a well-known database anyway, would it be possible to replace them with a SQL database instead? (You could even use a Hypersonic database, which can ship its data as deployable files, just like the sample data database we use in PRD) We normally recommend translation tables, where your SQL query chooses the text column based on the locale (You can use a query-script in the SQL-datasource for this selection logic.) or by using a Where clause (ie SELECT text FROM translations WHERE lang = ${env::locale-short}).

    However, even with those limitations, using the translation.properties will cut down your work to a few well-defined locations in the report files and will make sure you only have to deploy one PRPT file instead of 3.
    Get the latest news and tips and tricks for Pentaho Reporting at the Pentaho Reporting Blog.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.