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:
translate("MyWord")
This results in the header value being properly translated according to the locale of the session.
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.
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?
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.
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.
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.
[
"one",
"two",
"three"
]
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]
Result:
[
"uno",
"dos",
"tres"
]
As the final piece, right-click Table.custom.translated_headers, and select the onChange Script option. Youâll want to provide an onChange script:
if currentValue:
# 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.
After trying, the following error message appears, what might be wrong?
org.python.core.PySyntaxError
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â))
@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.
This has been resolved in the 8.1.45 nightly. You can now provide translations for the Perspective table's headers/footers and groups as long as there is a configured column or group property in the table's properties without using system.util.translate or the translate expression function.