In VC4, it was possible to use static text (for example, the title of a GroupBox) without linking it to any text group. These texts could still be exported to a .csv file, translated, and then imported back into VC4. This allowed us to display different languages without having every text in a text group.
In mappView, this behavior seems to have changed: static texts are no longer exported and therefore cannot be translated. Question: Do I now have to place every text I use – even simple, unchanging labels like GroupBox titles – in a text file to enable multi-language support? Or is there another way to make such texts translatable?
If you use the .tmx files (Localizable Texts and User Event Texts), these files can be easily passed through translation software as .tmx is a standard for language translation.
( Translation Memory eXchange - Wikipedia). In mappview, you can then add these files to the Text System and select them in drop downs in the mapp view content editor.
The online help (Text system) covers using the Automation Studio text system in mapp view.
If you aren’t using VC4, it’s a very good practice to use .tmx files for all your static and even dynamic texts (event logs, mapp alarmx, mapp view, etc).
I know how to use .tmx files in mappView and that you can select texts from these files in the Content Editor.
My issue is that in VC4 it was possible to simply enter a text directly into a TextOutput widget (without linking it to a text file or group). Then, during the text export for translation, these static texts were included in the export file and could be translated and re-imported.
Now in mappView, I have to create a link to a .tmx file for every text in order to use multilingual functionality. This creates a significant overhead for static texts that only appear once on the HMI, because I always need to go through the selection menu, choose the text group, and pick the text instead of just typing it in directly.
Is there any way to simplify this process in mappView, similar to how VC4 handled static texts?
I think the process to set simple multilanguage text like VC4 doesn’t exist yet. Would be a nice addition that in the background a tmx file is created and directly linked. These kinds of request should be send to the support department so they land at the product owner.
You can still export the multiple *.TMX texts files in a single CSV file and import it again in one go. File -> Text Export and import
I’ve been doing B&R for almost 20 years. The number of VC4 projects I had to come in and clean up have caused nightmares; all because people didn’t use text groups or style sheets and did the ‘simple thing’.
There were times where the costs of translations were shocking managers. The developers had used the embedded text ‘feature’ and had used the same bunch of texts strings in hundreds of places and translators were charging per line in the csv.
There were HMI’s where every single numeric had the same custom local style applied instead of using style sheets. I’ve had to write scripts to clear styling from thousands of VC4 controls so styling could be implemented cleanly with style sheets.
Allowing the simple, can create years and years of headaches.
I’m not saying B&R has a perfect UI, but developing around standards is a very good move. I’ve experienced mapp view since it’s earliest release when it only had content and page editors, not even a layout editor (all done in xml).
The old VC4 import/export of languages was not without issues and I’d helped plenty of developers with issues on the import, like when text snippet names had gotten translated.
If I were you, I would make a feature request. The content editor should make all statically entered texts automatically entered into its own .tmx file stored in the root mapp view/resources/text with the namespace IAT/embedded and that the namespace is automatically entered into a text system config file. Burying static texts in the content XML files also makes find and replace in those static texts more confusing.
Having a singlular file for text storage is beneficial. Having a tool that has to parse all the *.content files to look for static text to translate is far worse.