Where are the untranslated labels and data in 3.5.2 and 10.5.2?


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.

Continue reading

Why aren’t fields localizable after a platform-only upgrade?


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.

Continue reading

Why doesn’t the calendar picker work for dates past 31 Dec 2038?


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 3.4.2.1. 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.]

Continue reading

How do you localize a customized state family?


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?

Continue reading

Why does runDynamicQuery get English for non-English users?


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 3.4.1.1 / 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.]

Continue reading

How do you use translations to rename a form label?


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.

Continue reading