Problems with language translations

Good morning everyone.

I've been having trouble with translations for a while now (since 8.3 beta3). I have a series of labels containing the expression "translate("key")" that I use to translate from English to Italian and vice versa. I don't understand why it translates some terms while not others despite the correctness of the common keys. However, if I try to delete them and recreate them with a small difference (e.g. key --> Key), it works...

I noticed this problem when I switched from Ignition 8.1 to 8.3 beta3. I was hoping that now, with 8.3 Stable being released, this problem would be solved, but unfortunately it wasn't...

I also tried exporting the translation lists, deleting them all within Ignition, and reimporting them, but it didn't work.

Could anyone help me? The last solution would be to delete all the tags and recreate them, although I'd prefer not to do that :).

Thanks!

This isn't something we're aware of and we tested localization/translation pretty thoroughly in the migration from 8.1 to 8.3.

Are the settings in your translation manager the same? Check the 'Gear' icon on the right hand side of the translation manager interface in the designer:

There's settings in there to ignore capitalization/whitespace/etc - they should be preserved from 8.1 to 8.3 faithfully and lead to the same behavior, but maybe something's gone wrong there?

I checked, but the settings are the same.
They're all disabled, so I'm not missing anything.
The thing is, I can't figure out why some work and others don't...

Are you already working with our support department? I would really encourage you to do so, so that we can formally track this and have folks with some time investigate it further.

It's entirely possibly something broke in the 8.1 -> 8.3 upgrade and we're just not aware of it, so the more information we can get from you the better.

Perhaps the underscores versus dashes issue, as noted here:

1 Like

I’m having the same issues. I upgraded to 8.3 from 8.1. All my translations from English → Chinese (Simplified) still work except for instances where I have to use expression bindings. For instance on the X label on bar charts, I had to use expression binding on the data to translate. Since upgrading, I am getting errors.

After some troubleshooting, it looks like the issue was that translate() no longer recognizes ‘zh-CN’ as a locale. It does however recognize ‘zh’.

Yeah, it's a bug and we'll get it fixed, hopefully as soon as 8.3.2.

For now, if you pass zh_CN instead of zh-CN it should work as it did before.

No, I've only opened a ticket regarding the issue mentioned above by @pturmel (the one with the - and _). The response was this: "Our system is showing that there isn't a valid support plan and that you're not currently part of our integrator program. We have contacted your distributor, EFA, and relayed your ticket information."
Should I open a ticket for this issue as well?

A question, just to avoid doing the work twice, in the {session.props.locale} is it better to use "-" or "_"?

And as a function in the expression? Is it better "translate('somekey', {session.props.locale})" or "translate('somekey') ?
Thank you!

Another bug appeared with translation yesterday as well. Some words will only translate after you add them and then delete from the translation manager.

ex. I used the word “Dispersing Machine” and created a Chinese translation to “分散机” in translation manager. The binding however would not see the translation until I deleted it from the translation manager. So to get it to work, I had to add the translation, then remove it. Currently it’s working fine without the key even in the manager.

session.props.locale should be set with a BCP-47 language tag (in short, - separated).
The translate function should accept a BCP-47 language tag, but (one of) the bugs here is that it doesn't - that's a regression from 8.1 behavior we're treating as high priority and should be able to fix by 8.3.2. So you have to pass a "Java formatted" language tag (in short, _ separated) in to the translate expression function - but nothing else in Perspective will expect this format, so try to keep your changes isolated to uses of the translation function.

The fix in [1]8.3.2 will deliberately support both formats for the sake of backwards compatibility, so you won't have to immediately go back and rip out any changes you make to get things working until that next release..

As a temporary workaround I would recommend:
translate('somekey', replace({session.props.locale}, '-', '_'))
That will ensure the translation updates as the locale changes, but pass the (in)correct language tag format to the translate function that it's expecting.

This isn't something we're aware of, so I'd definitely request that you contact our support department with whatever information you can provide to help us replicate this as well.


  1. hopefully ↩︎

2 Likes