Using Perspective 8.1.
I've got a table defined, where each column has a header.title defined.
This title is a static, simple string; not set via a binding or programmatic method.
I added the header titles to the Translation Manager, with appropriate translations for my desired languages. However, when I change the locale, the header titles do not reflect the change.
I'm pretty sure I have things configured correctly as other text labels on the same page are updated to reflect the change in locale.
Are table column header titles not included in the automagic translation processing?
They don’t appear to be. I’ll check with Dev to see if there’s a reason. As a workaround, you could always bind the header values to an expression function:
This results in the header value being properly translated according to the locale of the session.
Thanks for the update.
Same issue with Tab Container headers. Can you confirm it doesn’t work for them as well?
I can work around it as you say (binding and calling translate), I just want to make sure I’m not missing something such that it’s taken care of “automagically” like the other translation processing for labels, etc.
Same question - is there a timeline to include table headers and tab containers in the normal translation process?
In most of Ignition, automatic translation is applied to constant strings that IA provides as part of the platform. Apparently except for label text in Perspective. User supplied text generally requires user invocation of translation. Why do you think the table headers you supply should be treated specially? When it would likely interfere with anyone who is following the current model?
I’m not sure what you mean…
Currently, in Perspective, if I throw a button component down, I have to supply a label, which Ignition will automagically translate for me (assuming I’ve configured the text in the translation manager correctly). This translation bit is true for most perspective components.
I would expect if I throw a tab container down, where I have to supply a label for the tabs, Ignition to automagically translate it for me as well. (I actually think this might have been fixed in a recent Perspective version.)
I know tables and graphs are a little trickier, as they are essentially handled by a third party component – but still, when configuring tables and graphs, I have to supply labels for column headers, etc.
I would just like the expectation documented somewhere if they are only going to translate label text for some components and not others.
Hmm. I’m going to have to play with this some more. (Still mostly in Vision, which doesn’t auto-translate much of anything.)
I agree with @ShaneH that it would be nice for more items to be cross referenced to the translation manager. A couple other examples of items that don’t translate automatically would be the legend on Time Series charts and the titles (including axes) and legend on XY charts.
For what it’s worth the PowerChart is better in that if you have a word used in the Power Chart in your translation manager it will get translated (except in the table headers), but you have to add them it seems.
We tried to bind header.title, but the translation display is one after one.
Do you have any suggestions for us to improve the translation speed?
The reason you’re seeing them pop in asynchronously is that the bindings each resolve independently. You could set up a single script to resolve al of the headers at once, but it requires some extra setup (even the following example could probably be optimized).
You could create a custom property which is an array:
Table.custom.headers, which contains all of the un-translated header names.
Create a second custom property:
Table.custom.translated_headers. Bind this to
this.custom.headers, and include a transform:
return [system.util.translate(header) for header in value]
As the final piece, right-click
Table.custom.translated_headers, and select the onChange Script option. You’ll want to provide an onChange script:
# this expects that you have already defined/created a column for every header you're expecting to use
[self.props.columns[index].header.title = title for index, title in enumerate(currentValue.value)]
Thank you very much for your quick reply. We will try it!
In addition, I would like to ask whether the time schedule allows the Table Header to directly transfer the language terms without binding?
If you’re asking about the Equipment Schedule component, and the months of the header or even the range dropdown, then yes - those pieces are translated somewhat automatically; months are automatic, but the range dropdown requires the ranges be supplied in the Translation Manager. This is because months are common and part of the “library” by default, whereas ranges are not. This sort of boils down to “December” only needing one translation, whereas “hour” and “hours” each need their own translation.
If you’re asking about a different part of that component, or a different component altogether, then you’ll need to be more specific and/or include a screenshot.
Sorry, I mean, is there a schedule to enable Table Header to be able to transfer language without binding just like Label Component do?
After trying, the following error message appears, what might be wrong?
SyntaxError: (“no viable alternative at input ‘=’”, (‘function:valueChanged’, 4, 45, ‘\t [self.props.columns[index].header.title = title for index, title in enumerate(currentValue.value)]\n’))
Ah, maybe you can’t do assignments with that syntax…
for i in range(len(currentValue.value)):
self.props.columns[i].header.title = currentValue.value[i]
@cmallonee hello, sorry for resurfacing this issue but it seems to be still ongoing on 8.1.33
The expression workaround is still valid, I'm just wondering if there is ongoing work on this and table headers will be localized as other components, or if the workaround is here to stay
Work has not started on utilizing the translation API for the Table component. It's definitely something we plan on fixing, but it's also a lower priority.
Thanks for the update, I will use the expression workaround and keep an eye on the changelogs then