DOTX052W errors and Translated webhelp classic UI labels not showing

[gill_oxygen]

The translated webhelp classic UI button labels in the strings-zh-cn.xml file I created aren't being picked up.

• Oxygen v 20.1 Webhelp Classic output

• Translating for Simplified Chinese (zh-cn)

• Following the instructions: https://www.oxygenxml.com/doc/versions/ ... bhelp.html

I am trying to translate the webhelp classic help window UI to Simplified Chinese (zh-cn), but the translated labels that I have in the strings-zh-cn.xml file I have created in the [DocBook XSL directory]/com.oxygenxml.webhelp.classic/oxygen-webhelp/resources/localization folder are not being picked up and I am getting the following types of errors reported for the Print (printThisPage), Link (linkToThis) and other UI buttons:
[DOTX052W]: No string named 'printThisPage' was found when creating generated text; using the value 'printThisPage' in your output file.

I had to create the strings-zh-cn.xml file and so I copied the en-us one, changed the xml:lang statement at the beginning to <strings xml:lang="zh-cn"> and put in the following translations to test and left the others as US English:
<str name="printThisPage" js="true" php="false">打印此页</str>
<str name="linkToThis" js="true" php="false">链接到此页面</str>

I’ve added the strings-zh-cn.xml file to the strings.xml file in the same folder with the entry:

<lang xml:lang="zh-cn" filename="strings-zh-cn.xml"/>

It looks like the strings-zh-cn.xml file is not being located as the webhelp UI is not even showing the US English labels that are there that I have not translated.

The translations that were in the /com.oxygenxml.webhelp.classic/oxygen-webhelp/resources/localization/strings.xml file that was there by default (as in, I didn’t need to create it) are working.

The map and each topic have the language set xml:lang="zh-cn" .

In the transformation scenario I have the following settings:
• args.dita.locale zh-cn
• default.language zh-cn

Any suggestions as to where else I need to make updates for the zh-cn webhelp labels to be displayed? I have this working for de-de, but the translation files were both already there and so I didn’t have to create them or add them to the string.xml file.
Thanks.

[ionela]

Hi,

Thank you for your feedback.
Could you please clarify if the source file is DITA or DocBook ? If it is DITA, the following procedure should be followed:
How to Localize the Interface of DITA Map to WebHelp Classic Output

Let us know if you need further assistance.

Regards,
Ionela

[gill_oxygen]

Thanks - that's exactly the issue. I had realised earlier this morning that I'd been looking at the wrong section and that I had to create the new plugins folder and file and run the DITA OT integrator
I've just finished doing the additional set up and doing a test and it's now bringing the translated webhelp UI labels through.
The only issue I have now is that the Contents and Search tab names initially display in Simplified Chinese and then revert to English, even though my browser is set to not translate Simplified Chinese. The other labels like the Print and Link ones remain in Simplified Chinese. This is a browser, not Oxygen issue though!
Many thanks for your help in directing me to the correct documentation.

[justyna_i]

Hello,

I have the same issue but for webhelp responsive and Spanish language, oXygen version 25.0.
I have used the instruction about adding a new language:
https://www.oxygenxml.com/doc/versions/ ... nsive.html

and it is still not picking the Spanish translations up. I don't know what am I missing. Can anyone help?

The translated webhelp classic UI button labels in the strings-zh-cn.xml file I created aren't being picked up.

• Oxygen v 20.1 Webhelp Classic output

• Translating for Simplified Chinese (zh-cn)

• Following the instructions: https://www.oxygenxml.com/doc/versions/ ... bhelp.html

I am trying to translate the webhelp classic help window UI to Simplified Chinese (zh-cn), but the translated labels that I have in the strings-zh-cn.xml file I have created in the [DocBook XSL directory]/com.oxygenxml.webhelp.classic/oxygen-webhelp/resources/localization folder are not being picked up and I am getting the following types of errors reported for the Print (printThisPage), Link (linkToThis) and other UI buttons:
[DOTX052W]: No string named 'printThisPage' was found when creating generated text; using the value 'printThisPage' in your output file.

I had to create the strings-zh-cn.xml file and so I copied the en-us one, changed the xml:lang statement at the beginning to <strings xml:lang="zh-cn"> and put in the following translations to test and left the others as US English:
<str name="printThisPage" js="true" php="false">打印此页</str>
<str name="linkToThis" js="true" php="false">链接到此页面</str>

I’ve added the strings-zh-cn.xml file to the strings.xml file in the same folder with the entry:

<lang xml:lang="zh-cn" filename="strings-zh-cn.xml"/>

It looks like the strings-zh-cn.xml file is not being located as the webhelp UI is not even showing the US English labels that are there that I have not translated.

The translations that were in the /com.oxygenxml.webhelp.classic/oxygen-webhelp/resources/localization/strings.xml file that was there by default (as in, I didn’t need to create it) are working.

The map and each topic have the language set xml:lang="zh-cn" .

In the transformation scenario I have the following settings:
• args.dita.locale zh-cn
• default.language zh-cn

Any suggestions as to where else I need to make updates for the zh-cn webhelp labels to be displayed? I have this working for de-de, but the translation files were both already there and so I didn’t have to create them or add them to the string.xml file.
Thanks.

[gill_oxygen]

Unfortunately I can't remember now what resolved it! What comes to mind to test are whether this is only an issue if you access the help locally - if you access it on a server is it OK? I remember having some issues with translation resolved by checking this. It's something to do with the browser not being able to execute all javascript functionality for local files.
Also, for us, we get an index.html and an index_frames.html file generated and we have to delete the index.html and rename the other one to index.html or we get some tab name issues. This may just be our install, I don't know.

[julien_lacour]

Hello,

Sometimes when the new labels doesn't appear in the output it means that the localization plugin hasn't been integrated.
Have you run the "Run DITA-OT Integrator" scenario before running your WebHelp transformation?
Did the new localization plugin name appeared in the console?

Regards,
Julien

[justyna_i]

Yes, I have run the integrator. I also tried to copy-paste the strings-de-de.xml into the new language folder (since german is working) and it did not help so the issue is with implementation, not with the strings file.

Hello,

Sometimes when the new labels doesn't appear in the output it means that the localization plugin hasn't been integrated.
Have you run the "Run DITA-OT Integrator" scenario before running your WebHelp transformation?
Did the new localization plugin name appeared in the console?

Regards,
Julien

[justyna_i]

How would I see in the console whether the new plugin appeared?
When I run integrator it show me this:
integrate:

configuration-jar:
[jar] Building jar: C:\Users\ji\AppData\Local\Programs\Oxygen XML Editor 25\frameworks\dita\DITA-OT3.x\lib\dost-configuration.jar

BUILD SUCCESSFUL
Total time: 1 second


It is possible that it does not integrate new plugin but I am not sure how to fix it if that is the case.

Hello,

Sometimes when the new labels doesn't appear in the output it means that the localization plugin hasn't been integrated.
Have you run the "Run DITA-OT Integrator" scenario before running your WebHelp transformation?
Did the new localization plugin name appeared in the console?

Regards,
Julien

[justyna_i]

I did try another browser and it does not help. I am really puzzled by this.

Unfortunately I can't remember now what resolved it! What comes to mind to test are whether this is only an issue if you access the help locally - if you access it on a server is it OK? I remember having some issues with translation resolved by checking this. It's something to do with the browser not being able to execute all javascript functionality for local files.
Also, for us, we get an index.html and an index_frames.html file generated and we have to delete the index.html and rename the other one to index.html or we get some tab name issues. This may just be our install, I don't know.

[justyna_i]

Thank you Julien!
Your comment made me think whether that new plugin is integrated at all. I did some tests with existing strings-en-en.xml (changing some strings) and my changes did not show. Meaning that I was editing the wrong place.
Apparently I have 2 locations that look very similar with oXygen 25.0 = two dita-ot folders. Turns out I was editing the wrong one.

Everything is working well now

[gill_oxygen]

Hi, glad that you have resolved it.
Running the DITA OT integrator and having multiple file locations in similarly named folders, and seemingly duplicated resources, makes it very complex.
I really recommend documenting the process and test driving the instructions on another machine (you can have your copy of Oxygen installed in 2 places) if you have time. In my internal documentation I have one Confluence topic which lists the location of every file involved in the translation of the webhelp UI! Documenting it (even if it's just a list of links to the Oxygen help articles) ensures that you have everything correct for when you have to do it again for another language, as by then you will probably have forgotten all the small, but really important details that you struggled with this time!
One word of warning, my understanding is that some of the translations provided with the Oxygen install are actually provided by external contributors, not Oxygen. We found that we needed to correct some of the entries, so it is worth getting the translations checked.

[Costin]

Hi gill_oxygen,

The strings from the DITA-OT plugins developed by us (WebHelp / PDF CSS) already come with our own translations which we translated using authorized partners specialized in translations.
However, if you noticed any incorrect translations in the default translations available for the strings from our DITA-OT plugins, feel free to point them to us and we will do our best to solve them in the future versions released.

Kind Regards,
Costin

[gill_oxygen]

Hi Costin, it was several years ago, so I can't remember which German entries we updated. I did have this one noted in my internal documentation though as an example as to why we recommended getting the entries checked by the translation company: "German entry for "Related Tasks" only has the first word translated." I think I was on version 20 then.
I did contact Oxygen support at the time, and that's when I was told that some translations were provided by external resources.
Many thanks