General Translation Advice

[Cheri677]

Hey, all! 

Using RH Version 2022.4.179.

My organization will eventually need our output (both responsive web and PDF) translated. I'm hoping to gather as much information on this process as I can, which I'm doing by scouring existing resources, but I figured I'd also ask for input here. 

1. Our ideal situation is that we integrate Machine Translation with an existing vendor, possibly SmartLing, with some human input and oversite. Does anyone have experience with this kind of hybrid approach, using both machine translation and some manual oversite? What is your workflow for that? 
2. Can you only translate output into the languages listed in the Translation Language dropdown menu? Or are you able to translate beyond that, to say, Urdu or Yiddish? If so, how does that work?
3. Any general advice from your personal experiences with translation services, either machine or manual, and how they interact with RoboHelp?

Thanks all! 

[Peter Grainge]

There aren't too many users of translation who also support the forum. There is one person who I hope might be able to respond but meantime there have been some recent posts on the subject. Take a look at those.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Jeff_Coatsworth]

Also search for "localization" and "XLIFF" too.

[WoutJacobs]

To question 1:

No experience with machine translations (MT), but the fundamental workflow is that you export the XLIFFs from RH, translate those XLIFFs, and then import them back in. Admittedly, RH has 'integration with MT' listed in its features but I wouldn't really trust that.

I note that some people tend to edit the translation project directly after importing the translations, which is pointless in the long run. When you make a new XLIFF export from your base project and import the translated XLIFFs back into the translation project, all edits are overwritten.

To question 2:

Interesting question, especially as those languages have a different writing direction.

We can quickly test this:

1) export the XLIFF in a random supported language pair (Hebrew)

2) 'Translate' the XLIFF in Urdu, ignoring the language code

Note that you may have to manually change the language code in the XLIFFs for the translation provider to be able to translate in that language.

3) Import it back

I'm not sure if the direction is respected (I doubt it), but the content works at least:

To question 3:

I honestly do not think the translation feature of RH is commercially viable in its current state, but that is my opinion. Using it out of the box will undoubtedly lead to some problems.

We use Trados to manually translate Dutch topics to French, and the entire process has been rather frustrating to say the least.

A non-exhaustive list of problems I've had to fix:

• Unsupported language codes: we use Belgian Dutch (nl-be), not Dutch Dutch (nl-nl) supported by RH
• Failure to export variables and glossaries: XLIFFs of variables and glossaries failed to be read by Trados. This seems to have been fixed in RH 2022.4 but I have no faith.
• Overly long file names: XLIFF file names are generated based on their position in the project (e.g. 'folder1_folder2_filename.xlf'). If you work with a lot of nested folders, you will hit that 255 character limit eventually.
• Dubious XLIFF conversion: RH works with segmentation when converting HTML to XLIFF (which you definitely should check if your translation provider supports), but the way it segments source sentences is not very robust. It discards empty tags and duplicates certain content if you use a lot of spans in your text.
• Folder structure problems: if you import a translated XLIFF into the translation project, the path structure must match exactly: a topic A in 'folder1/subfolder1/topic A.htm' can only be imported if you have the same folder structure 'folder1/subfolder1' in the translation project. If this is not the case, and you undoubtedly will rename folders at some point in your life, then the import will succeed but nothing gets imported. RH gives no indication of this.
• Endless importing bug: if your XLIFF file has empty target segments, RH tends to get stuck on endlessly importing during import.
• ...

If you have no technical knowledge within your company, you may be in for a rough time. I've had to design a five-step script to handle all these export-import problems:

1. pre-process all topics in the project to add text to empty tags so that RH does not discard them during XLIFF conversion.
2. post-process all exported XLIFFs so they conform to our language code + shorten XLIFF file names
3. Mirror the folder structure of the translation project to the base project before import
4. Revert the translated XLIFFs to their original file names
5. Post-process cleaning (mainly deleting duplicate variables due to poor RH XLIFF conversion)

It is mandatory to always check the translation output after every import.

[Cheri677]

Thanks very, very much for your comprehensive reply!

A follow up question--if you output frameless web content, how do you actually configure your output so the end user can toggle between languages? 

[gbr_555]

Hi Cheri, we tried a double-language online documentation with RoboHelp 2019 once - back then, there was no translation feature in RoboHelp itself but there's always a chance to translate the HTML output (we're on "Frameless" since it's available). Our approach was to link two separate content sets by a simple button in the page head. You can do the same for more than just two languages by putting those links into the footer as well.

• Create content sets in both languages, translated however you want it (see discussions above)
• Create a Frameless "skin" in RoboHelp that contains a button in the page head linking to the second language version. That's just a hyperlink, you only need to agree on a deep URL for both languages, such as blabla.com/en-us/home.htm and the respective URL in the other language(s). 
  Be aware of the folders you'll get in the RoboHelp output! If you're using folders in your "Contents" section in the RoboHelp user interface, then every folder there becomes a folder in the Frameless output, too. So if the "home.htm" (whatever your default topic is) will be put into a sub-subfolder in the output then that path must reflect in the URL you'll put into the language switch. The "/en-us/" part would NOT be part of that output, it's a folder in the webspace in which you want to publish the content for that language.
  For different languages you'll obviously need different skins with the according labels and UI buttons etc. in the respective language. So that language switch can link to different URLs for the respective twin site.
• In the output presets, make sure to set that "home.htm" (or whatever you've put into that deep URL) as the Default Topic (that's in the "Content" section of the Preset editor); leave "index.htm" as the "Start Page" in the "General" section of the Preset editor. This way, every browser starts displaying the content on this web default, and in that file there's the direction to the right folder/topic that you defined as the default topic.
• Generate the output in each language - these will be two separate websites, linked to each other just by that one button in the page head. Add the <href> attribute target="_self" to make sure the other language content opens in the same tab or window. 
• Set up (or let the IT guys do that) a webspace with that blabla.com domain, which contains those subfolders for each language. In case your IT guys are asking: This is, because each RoboHelp Frameless output comes with its own index.htm file that redirects to the default topic. That index.htm file will be slightly different for each language because it redirects to Default Topic in that language. That's why the language subfolder needs to be part of the URL you'll set into the language switch (the link in the header or footer).
• Publish the output stuff in the respective blabla.com/language-shortcut/ domain and breathe slowly for two or three minutes while the content gets distributed all over the content delivery network.
• Open the URL for the content in one language and click the switch - that should open the content in the other language. If something goes wrong here check the paths first: Is there a subfolder name missing?

[NoWeM]

1. I am not certain if this may be of assistance, but there is also the option of translating the Robohelp files without the help of Robohelp and then just generating the output (with Robohelp).
   This is the approach we are using as we have to deliver our help files in up to 40 languages and not all of them are supported by Robohelp.
   As a hint: As an external translation tool, we use MemoQ.
   What we do - in short:
   1. We create a Robohelp project in the source language, let's say English.
   2. We copy the complete project (all files, etc.) and put it into a separate folder "DE" (German).
   3. We use MemoQ as an external translation tool. For every file type in RH that needs translation, we create a special import filter in MemoQ (no magic behind this, has to be done only once).
   4. We load all the project files of the copied project "DE" to MemoQ and let the translators do their work - if they use machine translation, or human translators is up to them. They also maintain the translation memory, term bases, etc. for the respective languages. So everything related to translation is done there.
   5. We export the translated files from MemoQ to the "DE" folder. This folder now contains RH files with translated content. We open the RH project in this folder and create the output - and voila: translated output.
   
   Of course, there are some things to consider:
   - The file types that need translation from a content perspective are: *.htm (topics), *.hts (snippets), *.glo (glossary); *.toc (Table of Contents), *.var (variables); For all these types, you need a filter in memoQ (to separate content that shall be translated from content that shall not be translated).
   - You have to manually change the project language of RH to the target language (either via opening the project settings or changing the content of the languages tag in the *.rhpj file.)
   - This way you can also translate into languages RH does not support, there is just one additional thing you have to consider: there are some strings where the translation is provided by Robohelp, you would need to translate these on your own, for example, the *.lng file - this file contains the labels used for the output (for example, the label "Search" in the search field in responsive HTML output)
   If you have a not-supported language you have to change the project language to English and OVERWRITE these files, e.g. the en_UK.lng file (in the translated project folder), with the respective translations.
   
   One big drawback, of course, is that you have to remember if you changed anything in the source since the translation process started. In my case, we can handle that as we have one source and need to translate to 39 languages, but only AFTER the source is quite stable - so we do not have to change the source after we started the translation process.

[Cheri677]

Thank you, sincerely, for your reply! This is really helpful. 

A followup question--if you output frameless web content, how do you actually configure your output/site so the end user can toggle between languages? 

[NoWeM]

We create PDF and Responsive HTML 5 output (but I assume Frameless web content is handled the same?).
After translation finished, I create the output for every translation project separately, thus ending up with 80 different outputs (40 languages x 2 output variants). Then I hand over the PDF variant to our printing department and the HTMLs to the developer who implement the help to our product software. The software then recognizes which system language the end-user has and displays the HTML output accordingly. The user has no option to switch between the languages - beside changing the system language.
BUT I assume this is just the way we do it and in general it should be possible to implement the output in a way that the user could switch actively between languages. But this is not done by Robohelp (at least not that I am aware of), but has to be implemented separately.

[Peter Grainge]

@NoWeM is correct. RoboHelp does not offer any way to switch between languages. Please follow this link to report bugs or request new features. https://tracker.adobe.com. Post the link to your bug report / feature request in this thread and others can vote for it. The more people who do so, the higher it gets prioritised.

Meantime you could create a project with a single topic just listing the languages with links to each project output. It will create two browser tabs so not perfect. 

Otherwise it's something like @NoWeM has suggested, your developers detect the system language.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.