[IGN-4876]System.util.translate takes too long

Hello @paul-griffith, are there any news regarding this issue?
Honestly the ability to properly and efficiently translate texts in Ignition Perspective is a must have and being forced to use a workaround is starting to feel just wrong by a paying customer side: it has been months without any kind of proper feedback on the matter.

I'm quoting your message from November 2021:

I get that fixing bugs requires time, but at the same time we're on version 8.1.16 and nothing has changed. Moreover 8.1.17 nightly versions' changelogs don't seem to deal with this issue, at the moment.
Thank you.

@Davide3i
Would your solution not be faster if you executed it like pturmel said? Or are you already doing it like that?

Consider pre-translating all necessary static words into private session custom properties, where the translation is triggered only by changes in the locale. Then the heavily used expressions and transforms can simply reference {session.props.custom.translated.wo} or {session.props.custom.translated.pc} in a simple stringFormat() expression. (Bonus is that will avoid jython’s string interpolation in favor of java’s.)
(Possibly use an expression structure to generate session.props.custom.translated.* in one go.)

Hello @louagejasper!
Yep, we are already doing it like that, but we’re still talking about a workaround.
This and the fact the Translation Manager is still pretty bugged, it’s quite a turn down.
I don’t want to sound as overly critic, but locales management is not the best Perspective feature at this moment.

Ok, good to know!

1 Like

The core issue here with system.util.translate is fixed for 8.1.17; you will be able to test in tomorrow’s nightly build.

2 Likes

Hi everyone,
we’ve encountered the same issue with the translate() expression function on Ignition 8.1.28. This delay was significantly slowing down the entire Gateway and even caused unexpected errors in some cases.

I’d like to ask whether this problem has been fixed in newer versions (for example 8.1.31 or 8.3.x), or if it’s better to use the translation via scripting (system.util.translate) instead — i.e. if the script-based approach is more efficient or reliable?

I’m aware that newer versions have already fixed translation issues in some components (like tables), but there are still several cases where we need to use translations dynamically.

Thanks in advance for any clarification or feedback!
M.

I did experience slow translations with a 8.1.37 gateway.

It was really frustrating, and decided to come up with a solution of my own.

Essentially, this is somewhat of a drop-in replacement to the existing translate() expression function. All you have to do is perform a find and replace, search for translate( and replace with runScript('yourLibrary.getTranslation', 0, .

Put the below code in a scripting project library (I used yourLibrary in my example above)

def getTranslationTerms():
	from com.inductiveautomation.ignition.gateway import IgnitionGateway
	from com.inductiveautomation.ignition.gateway.script import GatewaySystemUtilities
	system.util.globals["translations"] = {}
	package = IgnitionGateway.get().getLocalizationManager().loadFullPackage()
	
	for translation in package.getAllTranslations():
		try:
			system.util.globals["translations"][unicode(translation.getSourceTerm())] = {}
			system.util.globals["translations"][unicode(translation.getSourceTerm())][unicode(translation.getLocale())] =  unicode(translation.getTranslation())
		except Exception as e:
			system.util.getLogger("badTranslation").info("following translation didn't work: " + unicode(translation.getSourceTerm()) + " " + unicode(translation.getLocale()) + " " + unicode(translation.getTranslation())) 


def getTranslation(sourceTerm, locale):
	try:
		locale = str(locale)[:2]
		sourceTerm = unicode(sourceTerm)
		if sourceTerm in system.util.globals["translations"] and locale in system.util.globals["translations"][sourceTerm]:
			return system.util.globals["translations"][sourceTerm][locale]
		return sourceTerm
	except Exception as e:
		return str(e)

and put this line in the gateway startup script and update script :

yourLibrary.getTranslationTerms()

Please note : In the getTranslation function, the first line removes the last two characters of the locale in the session.props.locale . This worked nicely for my case, but might not work for you so you might have to tweak this.

What this code does is store in globals all the defined translations.

As everything is already loaded, the call to getTranslation is much faster. I haven’t experienced slow translations since using this.

Also apologies, this is definitely not my cleanest code and can certainly be improved.

Also, I’m fairly positive using the scripting approach you mentioned (system.util.translate) will yield worse results.

Both system.util.translate and the translate expression function essentially do what you're doing - cache the system's full translation package internally for quicker lookup. If you (or anyone else) is still experiencing performance issues on recent versions I'd request you contact support with some details so we can get a ticket going and investigate internally. We definitely don't want you to have to reach to manual solutions like this.

1 Like

I’ve build that ressource on the exchange.

I don’t know if it’s something you could use for your usecase. Maybe some digging in the code will be required to understand and modify it.

One things sure, i don’t use the system.util.translate or translate expression in it.

Regards