Regarding the BIRT version 4.20 engine, there is an issue where the corresponding translation (localization) is not displayed.

[LubinLuo]

Locally, the TW (Traditional Chinese/Taiwanese) translation type was selected for the language, but the displayed result is reading content from the zh_CN (Simplified Chinese/Mainland China) file, and not reading the content from the zh_TW file.

[merks]

Can you clarify "Locally, the TW (Traditional Chinese/Taiwanese) translation type was selected for the language" to spell out exactly you locally selected that?

[LubinLuo]

The issue is that the parameters are being passed via the URL, but the BIRT engine is unable to interpret the &__locale=zh_TW parameter. It can only parse &__locale=zh_CN."

"The engine cannot parse the parameters zh_HK and zh_TW. When either zh_TW or zh_HK is passed as a parameter, the displayed translation result only shows the translation content from the zh_CN files."

"Therefore, I'd like to consult on why this functionality worked correctly in version 4.5, but stopped parsing correctly after upgrading to version 4.20.

[hvbtup]

Some thoughts: First of all, I don't think the BIRT source code contains special handling for this locale.

What happens if you choose a completely different locale like eg en_US in the URL? Does that work? Or even something like de_DE (with some made-up translations if you like) - just to make sure that the URL parameter is considered at all?

Or maybe the second part of the locale setting (TW in this case) is just ignored for whatever reason and then zh_CN is the alphabetically first file that matches the prefix zh.

Newer BIRT releases also use newer releases of various language-related libraries, eg. icu.

It might be a good idea to debug through this.

[speckyspooky]

I would assume that you have used a specific property file at report level based on the configuration of ressources.

I started some investigations and of course I figured out that the following locale names won't be resolved:

• zh_CN
• zh_HK
• zh_SG
• zh_TW

The ore reason of it is that the core library ICU4J doesn't use this name pattern like name - see locale definition ICU

Comparable namings from ICU are:

• zh_Hans_CN
• zh_Hans_HK
• zh_Hans_SG
• zh_Hant_TW

The property files use the original namings but the locale-classe of ICU needs the second naming.

@merks 2 questions to you may be you have an idea.

I created for testing a name mapping at the class ParameterAccessor to switch internally the locale name without changing the locale name from the URL. It works fine.

But why I does it? I figured out when I start BIRT with "-nl zh_Hant_TW" the following message occur and the locale name will be truncated to "zh_".

Question 01: It is possible to avoid the truncation of the start argument "-nl"?

Question 02: What is your opion to add such problem at the mentioned class? It think it isn't the best apporach to solve the topic but I have currently no better idea.

[merks]

I believe the -nl arguments can use only use standard locales as available java.util.Locale.getAvailableLocales(). I'd also be very surprised (shocked) if such things are not supported directly by the existing frameworks. After all, IBM itself supports icu4j and IBM is heavily into providing translations using standard names for the files/fragments.

In fact, if you look here, you can see the naming conventions used by Babel:

https://download.eclipse.org/justj/?file=technology/babel/babel_language_packs/I20230220-2200/2022-12

[speckyspooky]

The naming convention of Babel use the standard locale zh_TW for the property files. The same naming of is valid too for the parameter property files.

Only the internal locale match of ParameterAcessor cause the issue due to unmatched naming between ICU4J and Java-locale. If I have time I will add a small kind of locale name mapping to ParameterAcessor.