Multi language support

There is nothing built-in right now. We plan on building in a translation tool for the clients soon.

It would be nice if all the system texts that are ever displayed on View client screens could be exported to some CSV file, there translated by system integrator and imported back to enable switching between the View client languages.

Is there some estimated time of releasing the translation tool?

We don’t have an exact time for when it will be released but it is looking like around June 2013. The idea is that we can push all text through a translation map automatically. You can translate any of the strings to multiple languages and Ignition will automatically switch it based on the language.

+1

++1
We really need that. :thumb_right: :thumb_left:

+1

I was wondering how it was going with the multi-language support feature – is it still being worked on? If so, what will it look like and when is the scheduled release date?
Thanks!

Yes! It’s good idea!

Travis’ answer above is still accurate, this feature is one of the primary features of 7.7. It might not be done by June, since 7.6 is only being released on May 7th, but we’re going to try to keep the cycle as short as possible.

Regards,

Any update on this?

Any update on this?

Hi,

It is being actively developed. We should have something to show within another month or so.

Regards,

any news? :wink:
thanks!

Well, progress is being made… we should be showing it a bit at the community conference in a few weeks. Not sure when it will be release-ready, but I’ll let those who have expressed interest know when a testable preview build is available.

Regards,

wonderful. thanks.

great to read :smiley:

Also looking forward to this. We use multi-language regularly (in other HMI products) for plants shipped worldwide with initial development done in English.

Ideal multi-language support would respect ALL CAPS vs. other cases (should not use the same translation string for “BATCH” as for “Batch”, not get messed up by punctuation in strings (ideally would auto-escape as required), and automatically fill in the dataset with all native strings (the ones it was developed with) so only the foreign localization strings had to be added. The dataset should be easily modified in an external editor.

Extra points would be the ability to add/edit translations on the fly–in other words, if a translation is missing, support prompting for translation entry in the HMI, as well as support the possibility of selecting a string in the HMI and modifying its translation.

Hi,

Thanks for your feedback. I think we’ll have a few options for how lookups are handled, such as ignoring whitespace, punction, etc. On your case request, though: do you simply mean that it should be case sensitive, or do you mean that all caps should be handled differently?

One thing to keep in mind is that we will allow a “translation” for english as well (or whatever the base language is). This will allow for the use of more specific ids, when necessary. That is, normally the key will also be the base word, like “Batch”, but it could also be “Batch.1”, with “Batch” as the “english alternate”.

The ability to translate/add translations dynamically from the client isn’t planned, though maybe with the right scripting functions available, you could do something like this, if desired.

Regards,

Thanks Colby; that sounds good.

Regarding ALL CAPS, case sensitivity is definitely desired so we don’t need to do extra work to keep “BATCH” and “Batch” in the correct case when translated.

The option to have an English translation to allow more specific handling of certain instances should cover most other cases.

Scripting functions that would allow going from displayed string to translation DB to allow editing translations from client would be slick.

Hi Coby,

Do you have news about it? When do you think it will be released?

Thank you very much

Andrea