Report translations

AyMINE support generation of reports in various languages including data translations

• How to make multinational reports
  • Make template for each language
  • Reports without template
  • Translate data
  • SQL Methods for translation:
• Notes:
  • Data are not translated automatically
  • Efficiency and methods limits

All reports are called with request for language mutation.

If user activates report without the language definition, the system chooses:

• User-preferred language in case that user download the report
• Client-defined language when system is requested to save the report in the system

User can also request English version of the report regardless what languages are preferred.

How to make multinational reports

Report uses two separately managed sources:

• Template and stored translation
• Data

Make template for each language

Reports based on a template should have HTML template for each language mutation:

/<module>/lang/<lang-codee>/<object-name>_{<report version>|default}

The template contains both the template and the translation strings

Reports without template

For reports generated without template, system choses translation automatically. Nevertheless, templateless reports are not commonly used because they could never look pretty.

The automatically generated reports uses object field names translation from the client-application translation files and does no uses client-specific translations.

Translate data

Report does not generate the translations – uses has to call translation method for reported objects before starting the report. User also has responsibility that the translation is actual and correct.

The translation to the report language is used using the pre-prepared SQL patterns and methods:

• Use left outer join with the translation table to combine the translated fields with the original one:
• Use SQL-stored methods to get the object name and short description translation

1:  getSQLQueryObject (
2:  "SELECT ...
3:     ifnull(t.name, i.name) as name, 
4:     userDesc(responsibleID) as userName,
5:     transObjDesc('tskArea', tskAreaID, '{$rep->lang->value}') as area,
6:     ifnull(t.body, i.body) as body, 
7:  FROM <object-table> i
8:     left outer join sysObjTranslation t on 
9:        t.objectName = i.systemObject and t.objectID = i.tskInfItemID 
10:       and t.lang = '{$rep->lang->value}'
11: WHERE <ID-field-name> = {$rep->objID}");

Legend for the example:

• Line 3: Choose translated name if translation exists, or original name. Works correctly regardless the translation is defined or not.
• Line 4: Get name of the person – names are generally not translated and the same values is used regardless of the language (system currently doesn't support translation of the user names)
• Line 5: Requests translated name of the business area or original name, if does not exists translation. transObjDesc (as well as transObjShortDesc) works correctly even with virtual object and finds the translation even in case that object is another descendant of the same ancestor. E.g. transObjDesc ('tskArea', tskAreaID, '{$rep->lang->value}') finds translation for business area as well as for project or other descendant of the tskAbstractArea abstract object.
• Line 6: Choose translated content if exists or original, if translation is not available (the same as line 3) .
• Line 8: User LEFT OUTER JOIN to join the original table with the translation. The translation will not be mostly defined and so the left join is necessary.
• Line 10: Don't forget join with language definition – otherwise select fails because there might be translation to several languages.

SQL Methods for translation:

• transObjDesc (objectName varchar(32), objectID int, language char(2) ) RETURNS varchar(120) returns name of the object (translated or original)
• transObjShortDesc (objectName varchar(32), objectID int, language char(2) ) RETURNS varchar(300) returns short description of the object

Notes:

Data are not translated automatically

Predefined generation of the English language for multinational version are currently hard-coded in the client application. In case of request to generate various language mutation, system could open the language-selection dialog before calling. However, system update is necessary for that.

Efficiency and methods limits

The transObjDesc and transObjShortDesc are designed to be used for reports not for general purpose. They are not very effective because of searching all objects of the same ancestor. Do no use them for views used by the application to get list of objects.
(However, don’t bother to use them – all searches are based on index and are made in a small table.)