Concatenation in string translation

Good morning everyone.
I'm having trouble concatenating translated text strings. I write the expression this way (translate("Diameter") + " " + translate("Coil") + " 2" + " [mm]"), but unfortunately, when I change languages, the translation doesn't work, even though the Binding Preview is correct.
Can anyone help me out and tell me if this is a bug that will be fixed in future versions, or if it's just not possible and I have to create two different fields?
Thanks :slight_smile:

Translate expresion has 2 arguments:

translate(stringKey, languageString)

Try setting the languageString to the language you are using.

You can get that argument here (in perspective): Session Properties | Ignition User Manual

Try using concat()

For example I use with success concat( translate('Filtro'), " 1" )

Thanks for the quick replies, but unfortunately it doesn't solve anything for me. It's not a formatting issue, since in other fields I use the translate function like this: translate("Key"), and it works flawlessly. What's more, I see the live translations when I switch languages. Only when I try to perform a "compound translation" (as described above) do I have to change views and go back in to see the correct translation.

Unfortunately, this doesn't seem to work either... It's not a problem with the string construction, but with the functioning of the system function itself (translate("")) when trying to perform an "on-the-fly" language change in a composed string...

If you are saying that you change the language and the text doesn't update, but only updates when you change view (or even reloading it). It's a refresh binding problem.

Try doing this after changing the language.
pathtocomponent.refreshBinding(custom.prop)

This would re-evalute the expression and should show the correct text.

Wow, this works! Do you think this is a bug?

Not a bug. To rerun a binding automatically, the binding has to "see" a reference change. If you include the session's locale property in your expression, that would be a reference that would cause refreshing when the user changes languages.

2 Likes

So, if I understand correctly, you're saying to include an "if" statement that checks the "locale" property, i.e. the language, instead of using the "translate("")" function. Is my thinking correct?

No, use translate('somekey', {session.props.locale}) in your expressions.

Any expression that explicitly references {session.props.locale} will auto-refresh when the locale changes.

(See Daniel's first reply.)

1 Like

This works but now another problem arises: if I use the function "translate('somekey', {session.props.locale})", the "session.props.locale" property must be, for example, "en_US" while if I use the function "translate('somekey') the "session.props.locale" property must be "en-US" (this format, the other function, gives me an error saying: "Invalid locale format: en-US"). Depending on which one I use, I see the translations of certain texts working or not. Why is this? This is all quite funny :joy:

Ooooo! Now that is a bug. You should open a support ticket.

4 Likes

Yeah, we do some heroics in Perspective to support both "BCP-47" language tags (what everything should be using) and Java's locale to string format (which uses underscores and is proprietary to Java). In 8.3 inadvertently it looks like we dropped the Perspective specific logic for BCP-47 tags by mistake. We'll get it fixed.
For simple locales, a string replacement of a - for a _ should get things working for now.

3 Likes