I have a fairly big project coming to an end. Now is time start thinking about translate it to another language (russian in my case).
I made project in english and now I need to send all texts for translation to Russia, so that one of the russians will translate this to their language. How can this be done?
I know about export terms in Translation Manager, but output from this export is either XML or PROPERTIES (I never heard of that). How is this helpful? What can I (or the russians) do with this files? They can’t be opened in Excel (at least I can’t; or I don’t know how), so which ‘tools’ must man use to do translations?
In every other SCADA system I’ve used, there was export to either EXCEL or at least CSV format. You can then send this to other party, they translate the texts (usually in Excel) and send them back; I import them back and there you go…
So what would be the easiest way to translate texts from one language to another by third party?
Both are plaintext formats. But the advantage to using XML is to be able to use unicode text directly.
In a PROPERTIES file, unicode must be in hex 
#Locale: ru
#Fri Feb 05 12:01:06 EST 2016
Logout=\u0412\u044B\u0445\u043E\u0434
Login=\u041B\u043E\u0433\u0438\u043D
In XML, you can specify Encoding in the first line:
[code]<?xml version="1.0" encoding="UTF-8" standalone="no"?>
Locale: ru Логин Выход [/code]Yes, I know, they are plaintext formats. And I also know, that XML ‘better’ because of unicode.
But editing this files in plaint text editors (notepad, notepad++,…) is for us, programmers. Which know, what the ‘<’ and ‘/>’ and other ‘stuff’ means. For common people, editing this file is nightmare.
For example:
export of English text in XML looks like this:
[code]<?xml version="1.0" encoding="UTF-8" standalone="no"?>
Locale: ru .......[/code] Now, how to explain to someone in Russia, where and how to put Russian translated text, so that he will not break the regularity of XML code... [code]<?xml version="1.0" encoding="UTF-8" standalone="no"?> Locale: ru стеллажи Текущее состояние Сосредоточьтесь на выбранной сигнализации Значение события Время события ......[/code] So, they must look out for this: [code] стеллажи[/code] Translated text must be without quotation marks (but English text is...), immediately after translated text there must '' (in the exporter file, there is only '/>' after text), after English text there is no '=', but they must put '>', .... Now imagine that Exported file with English text to translate is more than 2000 texts (and that is not a lot for this kind of project)... How many mistakes would there be in the translated file? Who would deal with this mistakes? How much time will in waste to find mistakes, when you try to import that translated texts file?.... Translating in this form (or editing and adding translated text) is frustrating even for me; what about other people, know generally know only Word and Excel... If I would send exported English text in XML to Russian with all this instructions, how to edit it and be careful about, they would laugh to me...So, if this is the only way to translate text to another language, then this is the ‘poor’ way for users (us programmers and end users). And I’m disappointed about Ignition (or IA) for doing it in this way.
Until now (in other SCADA software, which we used), we always export all texts into Excel or CSV format. Customers were open this files in Excel, translated them, save in Excel format (or export back to CSV), send files back in we imported them in SCADA software.
What could be more simple than two columns in Excel: one is English text, the other is another language. No fuss with quotation marks, ‘<’, ‘>’, ‘/>’,…
Is there any kind of XML editor out there, which would allow editing this files in Excels ‘fashion’ (like table, with columns,…) and that is compatible with Ignition (so that files can be imported back in Translation manager without problems)? 
[quote]Is there any kind of XML editor out there, which would allow editing this files in Excels ‘fashion’ (like table, with columns,…) and that is compatible with Ignition (so that files can be imported back in Translation manager without problems)?[/quote]A quick Google search shows a huge number of XML editors out there. I’ve worked with some of the graphical ones before and they were quite easy to use.
If your translators like Excel, you can also import the XML to Excel and export back to XML after it’s edited. Overview of XML in Excel gives instructions on how to do this.
I am working on something to help you out. maybe a csv to .properties file. Working on the unicode to codepoint porions of it now.
Before I post here, I spend entire day on google and try number of XML editor but I didn't found one, that is compatible with Igniton (to import it back).
Any suggestions?
[quote]
If your translators like Excel, you can also import the XML to Excel and export back to XML after it's edited. Overview of XML in Excel gives instructions on how to do this.[/quote]
I don't want to be rude, but.... have you tried yourself?
I have and you can't import XML from Igniton to Excel because it uses DTD...
You said "my translators"...
They are not my translators; they are common people, from customer side, which work in production or maintenance and know the technical terms, which are used on the screen.
We never hire "professional" paid translators, because they don't know shit about technical terms and their translations are usually not usable (for automation and SCADA systems).
Superb. Thank you very much. 
I can say now that Excel exporting CSV with unicode stinks. Same for WPS office. You can export to a Unicode text file, but holy cats! that hoses over the English portions.
OpenOffice has better options, IIRC, so I’ll see where that leads…
Have I mentioned how much I dislike playing with Unicode? 
I think I’ve got it. I know it will work with two-byte encoding, anyway. Haven’t had a chance to check it out with 3- and 4-byte encodings yet. I’ll hammer those out as needed.
Attached is a window you can import that will handle the Unicode. There are also a sample input file to reference (created in OpenOffice), and a resulting output file.
To make the CSV file in a table format and working with Unicode, I’m going to suggest OpenOffice. It has more (and generally better) options for Unicode, and free is not a bad price. Just be sure to save it in UTF-8 
Notepad++ is an okay option too, but a grid view to edit is not available.
[attachment=2]Unicode Translator_2016-02-09_1052.proj[/attachment]
Thank you for your effort.
I tried it and it works (I didn’t tried it extensively).
But one thing I can’t figure it out:
How the hell can I get all my English texts from my Ignition project to openOffice?
If I understand this correctly, I must create csv file (in openOffice), put in all English texts, save it in UTF-8 format, send it to Russians (with the instructions about openOffice and UTF-8).
OK, maybe I can (and they will also, I hope) swallow this procedure…
But how to get all texts from Ignition to openOffice? 
Updated the window to give you options for both directions (properties <-> csv)
EDIT: Remembered I forgot to add the space substitutions 
Fixed now.
EDIT TO THE EDIT: Never mind. Removed file… Read further for explanation.
OK, kudos for your effort. I tried this, but…
This is your file output_ru.properties:
#Locale: ru
#Fri Feb 05 12:01:06 EST 2016
Logout=\u041b\u043e\u0433\u0438\u043d
Login=\u0412\u044b\u0445\u043e\u0434
This\ is\ a\ test\ for\ a\ full\ sentence\ translation.=\u042d\u0442\u043e \u0442\u0435\u0441\u0442 \u0434\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u0438\u0439.
When I put it in your project in properties->csv, this is csv file it outputs:
#Locale: ru,
#Fri Feb 05 12:01:06 EST 2016,
Logout,\u041b\u043e\u0433\u0438\u043d
Login,\u0412\u044b\u0445\u043e\u0434
This\\ is\\ a\\ test\\ for\\ a\\ full\\ sentence\\ translation.,\u042d\u0442\u043e\ \u0442\u0435\u0441\u0442\ \u0434\u043b\u044f\ \u043f\u043e\u043b\u043d\u043e\u0433\u043e\ \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430\ \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u0438\u0439.
I think, this is unusable…
Oh yeah. Just had a “duh” moment. I didn’t need to do anything with the spaces. It was already part of the export.
Well, as we say, it’s why we call it debugging… 
Here’s the original one. Before I broke it.
[attachment=3]Unicode Translator_2016-02-13_1200.proj[/attachment]
[attachment=2]2016-02-16_10-42-18.jpg[/attachment]
EDIT: It occurs to me (maybe another “duh” moment) that you may have had this in mind. This one should take care of that for you.
[attachment=1]Unicode Translator_2016-02-16_1134.proj[/attachment]
[attachment=0]2016-02-16_11-34-07.jpg[/attachment]
Testing with Japanese (Hiragana). So it works with 3-byte UTF-8 
[quote=“JordanCClark”]EDIT: It occurs to me (maybe another “duh” moment) that you may have had this in mind. This one should take care of that for you.
[attachment=4]Unicode Translator_2016-02-16_1134.proj[/attachment]
[attachment=3]2016-02-16_11-34-07.jpg[/attachment]
Testing with Japanese (Hiragana). So it works with 3-byte UTF-8 [/quote]
Yes, that’s what I need.
But… it’s not working.
The simple test should be:
- I create .PROPERTIES file from translation manager and convert it to .csv with your PROPERTIES->CSV function
- convert created .csv file (without editing it) back to .PROPERTIES with your CSV->PROPERTIES function
- import .PROPERTIES file to translation manager
The .PROPERTIES file, created from translation manager and .PROPERTIES file, created with your CSV->PROPERTIES function are not the same.
In file from translation manager, every space and special character is preceded by \ (backslash), and in your file spaces remain as spaces (without \ before space). So, when I try to import your file in translation manager, I get … not right…
There are also no = signs in your file (where is no translation for english text).
In the attachment are three files: one from my translation manager, one from your PROPERTIES->CSV function and third from your function CSV->PROPERTIES.
Thanks for the properties file you’re working with. That helped tremendously!
All right. After finding all the escaped characters (well, all I could find anyway), and going back and using Java’s regex instead of Jython’s, I think we now have a fully working version.
Let me know how it works for you.
THAT’s IT! 
Now it working, like it should. 
Thank you very much.
I think, this would help other people also… at least, when they come to the point of sending files to the other countries with another language…
What it’s not clear to me is, what were people at IA thinking, when they developed this translation export/import functions… why they didn’t implement something like this already?
[quote=“zxcslo”]
What it’s not clear to me is, what were people at IA thinking, when they developed this translation export/import functions… why they didn’t implement something like this already? [/quote]
I believe the intent was to handle all the translation entry from within Ignition. What we did is rather like Mythbusters: using tools and materials in ways for which they were not intended. 
As we saw in our exercise here, the problem with trying to make something absolutely universal is that the universe is a really big place. 
Throw in locales and different ways to delineate thousands separators and decimal places in numbers, and the ways that Java/Jython/Windows/Linux/etc. handle such things (or not handle, as the case may be)-- I get headaches just thinking about it.
Anyway, glad it’s working for you! 
For anyone interested in the future: I created a Python tool to convert the Translation Manager exported XML file to CSV and back from CSV to XML. You can check it out on GitHub: https://github.com/crooke/ignition-translation-converter
Here is the original project again. Thanks, @JordanCClark again for his help.
Ignition Localization PROPERTIES converter_2016-02-19_1258.proj (16.9 KB)
@ecrook
While you have all my respect for your contribution 
, I would suggest making this work in Ignition. Not everyone is running Linux or have python installed (like me).
Huh??
I didn't see anything Linux-specific in Eric's code on github. Whille every Linux distro I know has python in its base packages, python is just as popular on Windows.