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.
In our TRIRIGA Anywhere app, a user cannot login if the region is set to Panama on his/her iPhone. We can add a new Language to the system “Languages” list (e.g. “Panamanian”). A row can be inserted into the LANGUAGE_DETAIL table with LANGUAGE_ID referencing the LIST_VALUE_ID that was produced by adding the list value. This results in “Panamanian” being displayed in the Language Manager.
However, even though the LANGUAGE_DETAIL record indicates a value of “en_PA”, it is presented as “en_US” in the manager. It is possible to change the locale code and click “Save”, but appears to only accept the previously defined values. For example, changing any of the values to “en_GB” and saving works correctly. If an unrecognized code is entered (such as “en_PA”), it reverts to “en_US” upon saving. I’m not certain if there is a table somewhere that stores the “supported” region codes, or if it just uses the supported list of Java locales.
In terms of TRIRIGA globalization, some fields are not localizable after a platform-only upgrade.
With the introduction of TRIRIGA 10.3/3.3, a new field was added to Data Modeler for localization. If you have upgraded the TRIRIGA platform, but are on an older application version, the new field (Localizable) may not be marked for the fields on your business objects. To resolve the problem, in Data Modeler, check this setting for the fields in the business object that are not allowing localization.
When you try to use a calendar picker and the date is past 31 Dec 2038, that date is not available. It’s not possible to pick the date. The calendar picker browsing stops in December 2038.
The Dojo library timezone.js has 2038 as the maximum date. This affects any TRIRIGA environment up to 184.108.40.206. The workaround is to manually enter the date, following the correct format, taking into consideration the localization. The fix is available in Fix Pack 2 for 3.4.2, which is available in Fix Central.
[Admin: This post is related to the 08.07.15 post about APAR IV75813 where you cannot select dates past 31-Dec-2038 with the calendar picker.]
I have 2 questions about TRIRIGA state families, transitions, sub-actions, status, etc.
- 1. For customization in another language, for example, adding a custom state transition and sub-action, do you just type in directly in the language? Or should you enter English first, then use the Globalization Manager to translate? I know statuses are CL (classifications), so we should create records in CL first, then type in the exact same record names in the state family status, and previous status. Can you create the CL record in the foreign language directly, then enter the same word in the state family?
- 2. For the Globalization Manager, if I enter a translation manually, will the corresponding field in the XLIFF file get updated? If I export after the manual change, should I see the new value?
When I run a report as a non-English user in the UI, I get the correct localized value. However, when I run the report through the Connector for Business Application (CBA), I always get the English values, even though the user running the query is non-English. Is this a known problem? Has it been resolved in a later upgrade or fix pack? We have TRIRIGA version 220.127.116.11 / 10.4.1. Thanks in advance.
Have you tried running runNamedQueryMultiBoLocalized instead?
[Admin: This post is related to the 04.01.16 post about synchronizing the internal and localized values for key fields.]
I’m looking at the use of translations for renaming a form to keep things more upgrade friendly. For example, let’s say, I want to rename the “Real Estate Lease” form label to “New Form Label”. “Real Estate Lease” is something that is used throughout TRIRIGA in forms, queries, portal sections, navigation items, etc. In the past, I would just start renaming these objects, which ends up causing more maintenance at upgrade time as well as some unintended workflow issues.
I’ve heard that translations could be used to handle this particular use case, though I have never seen it in practice. Has anyone used translations in this manner? Is it a valid or good use of translations?
It is possible to use globalization tools for renaming any translatable labels in your system, but there is a caveat: “US English” users (using the new language as mentioned below) will not be able to update the internal value of the localized record field after an initial value has been set. This is because the US English users are now deemed as language users where values are stored in the language tables. To be able to rename the labels this way, you will need to…
Another possible solution (I have not tried this one), is to use the existing US English language. Follow the steps above except for the first step, then import the updated files with the “Auto-Detect Target Language” option checked or select the US English from the “Target Language” field. If this works, US English users will continue to be able to update the internal values of the localized field as long as the database language of the system remains US English.