I’m evaluating Ignition as an alternative to our current HMI software. Everything looks excellent, but I can’t seem to figure out the cleanest way to provide multiple language support for alarms. The alarm status table stuff is fine, but the messages themselves is where I’m stuck.
It appears to me that the best place to put a message is in the Display Path field because it shows up nicely in the native Alarm Status display object as well as the Alarm Status Table. However, there is no obvious way to make use of the Translations manager to facilitate changing the text in this field.
I see in another string of posts, that the intent is not to put user type data through the translation manager because we developers are responsible for the messages in the first place. OK. But, exporting the tags into XML does not give an easy format to hand over to the translators. They would have to sift through the file and translate 1 line out of every 8-10 lines. It also doesn’t allow for dynamic switching while on-site. (For instance, the customer machine is set up for Greek, but I don’t speak their language, so I can’t read the alarm messages while trying to help them troubleshoot)
I see that the Display Path can be set to an expression, so I would like to know what the easiest way to make use of it…
- A case statement would be very difficult to maintain because I would have to add the proper condition and translation for every alarm for every language.
- I could possibly tie the text string to a PLC register and use an indirect reference or program the PLC to copy the proper message set to the HMI-read registers. That’s possible, but it uses space in the PLC for no reason other than the HMI can’t handle it.
- The third possibility I see is to put the alarm messages into the SQL database and pull the proper description either directly from an alarm table or a stored procedure.
- I just found the function translate(stringKey). Could it be as simple as calling this function with an argument like “A001” and it returns a nice, full description? Where does the function get its translated text from?
Thanks,
Ken
According to the documentation, yes it will access the global translations setup for the project.
docs.inductiveautomation.com/di … ranslation
and
docs.inductiveautomation.com/di … /translate
The translate function works in other locations, such as the text property of a Text Field, but it doesn’t seem to work as the Display Path for my alarm.
For instance, I’ve tried concat("Alarm " , translate(“A00705”)) and it works perfectly in a Text Field giving me “Alarm Test Description in English for A00705” and when I switch to Spanish the message changes appropriately.
When I use the same expression in the Display Path for my alarm I get “Alarms/A007/A00705” which is the default path if I nothing in the Display Path box at all.
(I also tried the translate function without the concat function and had the same default result. When I try the concat without the translate function, the concat works correctly and puts the 2 strings together in the alarm’s display path. It just doesn’t have the translated text)
I have noticed something quirky with the display path on alarms, make sure you click Configure button, then select Expression and put the expression in there and click OK. If you just try to type or paste the string into the box on the main alarm config page it won’t take as an actual expression.
When entered properly, the Display Path listing on the alarm should turn BOLD, meaning something has been assigned to it.
For the alarm, I was successful changing the Display Path to static text and the concat function by doing exactly what you suggest, and it does go bold. It’s just when I introduce the translate function to the string, it stops working.
I’m hoping one of the moderators has access to a programmer, who can then explain why the translate function doesn’t work in this location. Even better, a work-around?
The display path for the alarm is evaluated in the Gateway, and translate() only exists in the client.
So I guess the $64,000 question is, how do we translate alarm text? 
1 Like
Thank you, Kathy. I can see how that makes sense.
So, if the alarm display path text is captured at the time the alarm occurs, whether or not a client is running, can the server pick up the translation from its own language setting?
Or, could the translate function have an additional parameter for desired language? Then, the alarm display path could pick up the alarm condition from the PLC plus the current language (a register also in the PLC) and translate it at the moment it occurred.
I realize the client will only see the description of the alarm in the language at the time it was created, but at least it would much easier to deploy in foreign countries.
Right now, translation doesn’t exist on the gateway, so it’s going to be a roll-your-own kind of thing. What I see users do most often is either the database lookup, the alarm going out has both languages in it, or the alarm pipeline branches, with each branch having a different language/roster combination.
Long term we’ll have to deal with being able to translate in the Gateway (and for sure, the language will have to be specified at the time of translation), because reporting in 7.8+ has the same issue – reports are executed on the Gateway, so using translation is not possible right now.
The best way to accelerate this is by voting at ideas.inductiveautomation.com. Someone has suggested it for reports, so you could either make a new idea or vote for that one and add a comment about alarms needing translation, too.
I found a way to do this using the translate() expression function. The limitation I have is I am not able to dynamically set the language string dynamically from a UDT.