I’m seeing issues within report results, where if the user profile language is in US English, the results are of one type, but if the user profile language is in German, it is showing some other data. The record while checked is the same for both cases. While opening and checking the record, the ID and name of the record varies from what it showed as a result in the report. While investigating, what we observed is that these fields are marked as “Localizable” in Data Modeler. What is the use and impact of the “Localizable” field property? Any suggestions?
Various existing users with non-US English language profiles are getting the following error when they click on the System tab on each form:
An Error Occurred. Contact your System Administrator. – [MID-3402867005]
When translating object references, the platform needed to catch the “smart object not found” error, and follow the path as if it was non-translated. Moving forward, when invalid data is contained in a reference field (like System Geography), the platform will no longer throw a MID error, and will now show the field as blank, since the referenced record does not exist.
A query generates multiple SQL statements that translate the UOM for every line in the report, when the user is in British English. The report template executes the exact same SQL over 3000 times.
The report runtime engine needed to make a call to get UOM data from the cache, not query the database. Moving forward, UOM values used in queries and reports are now read from the cache. Previously, they would be queried from the database, leading to a slight performance hit.
In the Attachments tab, this package contains the untranslated labels and data delivered in IBM TRIRIGA Platform 3.5.2 and Application 10.5.2. These will be translated in the future release. You can use the files inside this package to provide translations for your supported languages, then import them into your environments.
I am wondering if it is possible to export a user-friendly Microsoft Excel spreadsheet from TRIRIGA with the English translations in one column and the French, Danish, Chinese, or other language in another column (with one spreadsheet for each target language). If so, then this file could be uploaded back into TRIRIGA and the translation would be updated.
TRIRIGA only supports language packs in XLIFF file format, and they must be in this format for importing via Globalization Manager. This is why the export utility also generates the XLIFF format. You may have some luck with third-party tools to convert an XLIFF file into an Excel file. But it’s important that you convert it back to an XLIFF file with the same structure as the files in our shipping language packs. For example, tags like <tririga> and its attributes would need to be retained as-is.
Why is my language not showing correctly in my exported translation file? When I export a translation file from Globalization Manager, and open the XML file, the header will show the source language as “en_US” (US English) and not the actual language that was used for the export.
To resolve the problem:
- Go to Globalization Manager.
- On the far-right side of the screen, select Language Code…
- In the leftmost table, it will show a list of languages with the codes for the System Languages.
Verify that the language you exported to has the correct System Language listed. If the language you are using that did not export correctly, then you would use the Language Two-Letter Code table and Country Two-Letter Code table to create the System Language. For instance, if you needed to update the entry for Spanish because it said “en_US”, you would then enter “es_ES” according to these tables.
Disclaimer: TRIRIGA encourages using the latest platform release when installing new TRIRIGA databases. This ensures that you have the latest platform with fixes to known issues. However, if you need to stay at 3.4.2.x or 3.5.0.x and are installing into a non-US English database, review the following as you might encounter issues.
An issue has been found during the create table and/or use of the REP_TEMPLATE_HDR table when using a non-US English database. How the issue exposes itself and how to resolve it are dependent on the database type you are using. See the following instructions for how to resolve this issue for 3.4.2.x or 3.5.0.x.
On a non-US English database, you might not be able to install. You might see an exception similar to following in your ant.log file although the words in red will be in the language of the Oracle server. The SQLDataException will be ORA-01858…
Microsoft SQL Server Database
On a non-US English database, you should not run into the database installation issue encountered by Oracle, but you might get an exception when creating a new report or query or possibly when starting up your application server. If the exception looks similar to the following example, follow the steps below to resolve the issue… The exception in red will be in the server language. The English translation is approximately “Failed to convert the date and / or time from a string”…
IBM DB2 Database
IBM was unable to reproduce the issues in an IBM DB2 non-US English database. However, if you do encounter issues, follow these steps…