When you run a query expecting JSON results, via the integration object external URL functionality, the modified names of the roles are not being reflected. That is, the original name is displayed in the result query. This happens for localized users only. Meanwhile, US English (US_en) users observe the proper changes when refreshing the query results…
As I’ve understood it, both the integration object and DataConnect allow you to import localized data (except business key fields, I think). In addition, we have another option to use the Globalization Manager to import traditional data. I found it’s pretty cool. We will only deal with the localized data, with less impact for the non-localized data. Before going forward with an option, I’d like to know what’s the best option for you guys?
Importing by using the Globalization Manager updates the L_ tables directly. If your data does not include localized values that need to be concatenated, for example in a formula, the Globalization Manager import is your best option.
However, if your data includes localized values that need to be concatenated through a formula, or if your data needs to be processed by workflow before it is added to the TRIRIGA tables, then you should use either the integration object or DataConnect.
[Admin: This post is related to the 03.02.16 post about best practices for integration optimization.]
If a parent building has been renamed, a localized user cannot find that parent building in the lease by searching for it. You may test directly in Portfolio > Locations and may be able to find that for a localized user, the name of the building is modified. But that change does not flow to the column named “Building”. That is ultimately the building name used in the query inside the Lease record…
The root cause is that the query that displays the list in Portfolio > Locations is “Location – Manager Query – Manage By Hierarchy”. The field that is displayed in the column labeled “Building” is triParentBuildingTX. In the Data Modeler for Location > triBuilding, the Localizable property for triParentBuildingTX field is not selected.
Launching a record by clicking the link for a record in the tabular section of a metric report throws an error. This was reported for the French language and might impact other localized users and non-localized users.
In the user’s home page, click on the “Indicateurs” link in the second portal section on the left. In the metric scorecard, click on the first (note there are 2, you want the first) “Nombre de demandes” link. Then click on any of the records returned in the table format on the lower right. The system opens a window, but throws an error…
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.