2025-01-02 07:01 AM - edited 2025-01-02 07:02 AM
When trying to import simplified Chinese characters using an excel sheet, the xml database doesn't receive any input. When renaming the English column to the Chinese identifier, it does import the text assets. Is this an issue in the translations.rb script?
When copying the Chinese text from within the excel sheet to TouchGFX Designer, the text does appear, but this is quite labour intensive
Solved! Go to Solution.
2025-01-14 05:43 AM
Are you referring to this:
The double && is on purpose. Without, it will be converted to a newline character in the XML file.
We prefer to have in the text. Some editors (emacs) shows it with a line break:
For your other issue I found one problem.
In your XML you have the languages:
<TextDatabase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="texts.xsd" Version="4.24.0">
<Languages>
<Language Id="EN" />
<Language Id="CH" />
<Language Id="CHtest" />
</Languages>
In the XLSX you have the following:
So the languages are EN, CH, JA, KO, CHtest. Could be ok as long as you do not import JA and KO.
But the translations.rb tool gets confused, and fails to import CHtest.
I works after a little modification in translations_io.rb line 148:
The original code did not append to the header array, and the language indeces were wrong.
2025-01-02 11:42 PM
Update:
When importing an excel with the chosen language as only column, next to the English column, it does work if in the unsorted text resources, the wildcard values are copied first. It seems the script expects a language in the xml database to have all wildcards present before importing.
My current solution is to create a new language by setting initial values to an existing language and creating different versions of my excel file with columns removed.
2025-01-03 12:05 AM
Another update:
Languages to be imported have to placed starting in the second column at least and no languages that aren't imported can be in between
2025-01-03 02:16 AM
Hello Brecht
Could you provide a small Excel file that does not work with the simplified Chinese texts. I would like to check what happens. We can definitely improve the error messages.
You can also take a look if you like ruby :) You have the source code.
Best Regards
2025-01-06 02:10 AM
2025-01-06 02:18 AM
Hi
Thanks. We will take a look.
Could you provide the texts.xml file also. The one you are trying to import in to.
Thanks!
2025-01-06 06:41 AM
2025-01-10 03:28 AM - edited 2025-01-10 03:28 AM
I've been busy creating a script to automate creation of wildcard ranges and characters when importing translations and looked further into the ruby files, and an issue I discovered is that newline characters " " were present in texts.xml and were changed by the xml writer (touchgfx\framework\tools\textconvert\lib\xml_writer.rb) changes these to "& ", invalidating the xml file.
Perhaps this is a different issue, but I haven't been able to look into the original issue yet
2025-01-14 05:43 AM
Are you referring to this:
The double && is on purpose. Without, it will be converted to a newline character in the XML file.
We prefer to have in the text. Some editors (emacs) shows it with a line break:
For your other issue I found one problem.
In your XML you have the languages:
<TextDatabase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="texts.xsd" Version="4.24.0">
<Languages>
<Language Id="EN" />
<Language Id="CH" />
<Language Id="CHtest" />
</Languages>
In the XLSX you have the following:
So the languages are EN, CH, JA, KO, CHtest. Could be ok as long as you do not import JA and KO.
But the translations.rb tool gets confused, and fails to import CHtest.
I works after a little modification in translations_io.rb line 148:
The original code did not append to the header array, and the language indeces were wrong.
2025-01-14 05:49 AM
Aha, thanks!
For the line break, I had the weird issue that when calling the translations.rb script from a Python script, the double & would actually get written to the xml file, so it would come out erroneous, but I fixed it by removing the line breaks, because they were not needed and probably inserted into the translations by accident.