Translator's involvement with Flare

This Forum is for general issues about MadCap Lingo
Post Reply
fchan
Propeller Head
Posts: 47
Joined: Fri Aug 31, 2012 11:41 am

Translator's involvement with Flare

Post by fchan »

There was a thread about how people had Flare projects translated but it was kind of old. With the release of Flare v. 9 and Lingo v. 7, I'd like to restart this discussion. Specifically, I'd like to know which approach most Flare users use for localizing their projects:

(1) Use Lingo before zipping and submitting a Flare project to a translator. After the translation, import the files back into Flare and then generate the targets. This seems to be the workflow documented by Madcap, allowing translators who don't have Flare to translate.

(2) Submit the Flare project to the translator. Ask the translator, who has to be familiar with Flare, to return Flare projects in various languages as the translator's deliverables. (Whether the translator uses Lingo in the process is up to him/her.) Then generate various targets from the projects. (Or ask the translator to generate the targets.)

I think both approaches work, but I'd like to know what your experiences have been with each. Thanks!
Msquared
Propellus Maximus
Posts: 848
Joined: Mon Aug 06, 2012 10:19 am
Location: Southampton, UK

Re: Translator's involvement with Flare

Post by Msquared »

Not really an answer, but I've been wondering about this too. Here are my musings . . . .

I've just been involved in sending my first batch of Flare content to translators and receiving it back. This time round, we did it as we used to do it with the old Robohelp content, but I too have been wondering about using Lingo next time to package the content to be translated, and perhaps to start generating a termbase. I'm just doing a bit of experimentation now in my spare time.

Up until now, we've just zipped the source project and asked for translated output projects back, then incorporated the translationed outputs, as built by the translators, in our final product. This time round, the translators didn't seem to be bothered by being offered Flare content rather than Robohelp (we did warn them first!) and they seemed happy to generate Flare targets and return those to us with the translated sources.

What I wouldn't want to do is give them Flare projects and just let them return Flare sources to us without ever building the output. This time, out of my 14 languages, I had a couple of translations where the targets built with errors when I rebuilt them, and in each case, this indicated a problem in the translated content. This may have been because they had trouble identifying exactly what they needed to translate from the Flare structure. So it may have been a consequence of giving them the whole Flare project rather than just the strings that needed translation, as I understand that Lingo will.

Also, in one or two cases, the tranlators needed a bit of prodding to locate what to translate, for example, variables, text in the skins, any text in the stylesheets. I don't know whether Lingo will handle this better. I'm hoping that LIngo will extract all such fragments and include them in the XLIFF file. Perhaps too otimistic?

We have a slightly complicated workflow, since one of our products is a lite version we supply (at no cost) to OEMs. All our translations are paid for by the OEM. We ship the content to them, they ship it to the translator who translates, and then the OEM ships the translations back to us. We do benefit from being able to use the translated content in our own product too, but that is seen as incidental, rather than essential. So, since there's not a lot in it for us, my management is, quite rightly, reluctant to do anything that costs us too much, or adds too much of an overhead to the translation process. So that's why, up until now, we've adopted rather a hands-off approach to the translation activity.

Unfortunately, the lack of direct involvement does affect the quality of the translation. I can see that it has been variable, since we've not been able to generate a termbase, to ensure consistent translations for technical terms, or identify which phrases whould not be translated, or even, it transpires, clarify what strings should be translated. So, for us, Lingo is an option only if it is likely to reduce the time spent managing translations, not increase it. Unfortunately, if I can show that it will improve the quality of the translation, that on its own will not be enough to make a case for using it, especially if, in order to improve the quality of the translation, I have to spend more time interacting with my projects or the software. I will need to show that it will save me time too. So not sure about that yet.
Marjorie

My goal in life is to be as good a person as my dogs already think I am.
fchan
Propeller Head
Posts: 47
Joined: Fri Aug 31, 2012 11:41 am

Re: Translator's involvement with Flare

Post by fchan »

I should add another approach to my original post:

(3) Submit the Content folder to the translator. The translator then translates the XML files in the folder and then return it. Duplicate the original project and then replace the English Content folder with the returned Content folder (with the translated files in it). Then generate the output from this project. In this case Lingo is not used and the translator doesn't use Flare either.
Msquared
Propellus Maximus
Posts: 848
Joined: Mon Aug 06, 2012 10:19 am
Location: Southampton, UK

Re: Translator's involvement with Flare

Post by Msquared »

The problem with option 3 is that there are things in the Project folder that may need translation too.
  • For example, the .fltar file contains variables, some of which may need translation (one of my variables for my PDF output is the Document Title, as I have several rebranded versions, each with different titles, that I single source from the same Flare project).

    Another example, the .fltoc file contains labels for each topic that appear as the names of the topics in WebHelp. These too will need translating.
If you use Flare's Project > Zip Project, the zip will include all the project files that Flare thinks are relevant to recreate the project, which may be a better option than either your option (1) or (3).

Have you asked the translators what they would prefer? Our translators seem to be happy with Flare input, and clearly have tools to convert Flare XML content into something that their preferred translation software can read. I'm beginning to think that for me, the best approach is to carry on delivering Flare projects, which saves the overhead of exporting from Flare to Lingo, and re-importing back again. This also means that I can ask the translators to generate the outputs, check they are error-free and return them with the translated Flare projects. This helps to ensure the quality of the translation. If they've broken any links or missed some content, it will be obvious, hopefully to them before they return the files to me, but if not, to me as soon as I look at the outputs. It also means that if I have any trouble building the final outputs from the translated projects, I can compare my build with theirs to help diagnose the problem.

This approach didn't seem to bother the translators at all, indeed the Russian translation was returned complete with the Flare Russian Language skin, which was missing from the Flare 8 installation, so they were obviously familiar enough with Flare to know that was required.
Marjorie

My goal in life is to be as good a person as my dogs already think I am.
fchan
Propeller Head
Posts: 47
Joined: Fri Aug 31, 2012 11:41 am

Re: Translator's involvement with Flare

Post by fchan »

Yes, I think if the translator is willing to handle Flare projects, it would be preferable to hand him/her the Flare project. But if the translator has never heard of Flare, or has heard of Flare but is unwilling to handle yet another software, I'd like to know whether there are other options that are relatively risk-free. Thanks for the insight!
SolenaLeMoigne
Propeller Head
Posts: 21
Joined: Mon Feb 11, 2013 1:23 am
Location: Mérignac, France

Re: Translator's involvement with Flare

Post by SolenaLeMoigne »

Tip: request from your translator or translation agency they use SLD studio 2011 with the plug-in for Flare projects.
Also, specify clearly which files you want them to translate, and which files you don't want them to translate. We've just done that and all in all it works much much better (from my point of view) than going through Lingo as I was doing before. Sorry MadCap, but that's my experience.

If you check other posts, you can see I've used Flare 9 with Lingo 6, then Lingo 7, and the issues encountered with mixed-up markings cost us three weeks on this project.
Part of it is due to the fact that I upgraded to Lingo 7 between the moment I sent out the files for translation and the moment I received them. Don't ever, ever do that. The other part is the quality of the XML generated by LIngo. I am still waiting for more information from their terrific support team, but some tagging is not strict enough to Trados's taste and the resulting translated files cannot be integrated back in to Lingo.
Moreover, some segments seem to be locked in the TM, and I have found nowehere how to unlock them in Lingo, so the translation agency had to unlock them for me.
- Solena Le Moigne
Don’t worry, I’ll merge all those markups onto a single copy - Wade Nelson - techwhirl.com
alt_jennifer
Propeller Head
Posts: 57
Joined: Mon Mar 08, 2010 12:33 pm
Location: Fayetteville, NC
Contact:

Re: Translator's involvement with Flare

Post by alt_jennifer »

For Msquared, I would say that if you send only Lingo files to the translator, and import the translated files back into Lingo before generating the Flare project yourself, that will definitely increase your own time working on translations. Many people don't realize it, but there's a fair amount of work involved in finalizing a translated Flare project, that Lingo simply will not do. One example: if you have a Chinese Flare project, the fonts in the stylesheet all have to be changed to Chinese fonts. Lingo does not do this, or allow you to do it yourself in the Lingo project. So, it has to be done in the exported Flare project. Column widths might have to be adjusted to fit text, italics might have to be changed to another type of formatting for some languages that don't use them, page breaks might have to be adjusted, etc... Those are just some example of various fixes that may have to be done manually in the translated Flare project. Not to mention that everytime a Flare project is translated, the outputs should be proofed by a linguist -- which means that implementing any corrections rests on your shoulders.

So for both Msquared and fchan, the simplest approach to translating Flare projects is to send your entire Flare project to a translator or translation agency who really knows Flare. Not just someone who claims they can use it, but someone who really knows it. A vendor like that will know exactly where all the translatable content is found and will be able to generate complete and functional outputs. So when you're evaluating a vendor, be sure to ask questions about both the translation side and the Flare side of things. Ask questions that really tell you they have expertise in Flare, because some vendors might say they can use it but have to quickly try to learn it -- and they might not provide the best deliverables, they might require extra help from you, etc.

Just my two cents!
Jennifer Schudel
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
Msquared
Propellus Maximus
Posts: 848
Joined: Mon Aug 06, 2012 10:19 am
Location: Southampton, UK

Re: Translator's involvement with Flare

Post by Msquared »

Thanks Jennifer. That information is really useful and confirms that I've made the right decision for my translation workflow.

I'm a bit removed from the translation process, since one version of our product is an OEM version, and they organise and fund our translations. So I don't deal directly with the translators, and historically we've had minimal involvement due to lack of resources. So much of the translation process is a mystery to me. We have Chinese (x2), Japanese, Korean and Russian translations. I think I'll stick to sedning and receiving Flare projects!
Marjorie

My goal in life is to be as good a person as my dogs already think I am.
alt_jennifer
Propeller Head
Posts: 57
Joined: Mon Mar 08, 2010 12:33 pm
Location: Fayetteville, NC
Contact:

Re: Translator's involvement with Flare

Post by alt_jennifer »

Ah yes, those languages are some of the more difficult to deal with in Flare -- not that Flare can't handle them, because it can. There are just so many extra considerations than in English and European languages, and more potential customizations needed. Smart not to have to deal with them, if you don't have to!

Glad I could help :)
Jennifer Schudel
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
SolenaLeMoigne
Propeller Head
Posts: 21
Joined: Mon Feb 11, 2013 1:23 am
Location: Mérignac, France

Re: Translator's involvement with Flare

Post by SolenaLeMoigne »

SolenaLeMoigne wrote:The other part is the quality of the XML generated by LIngo. I am still waiting for more information from their terrific support team, but some tagging is not strict enough to Trados's taste and the resulting translated files cannot be integrated back in to Lingo. Moreover, some segments seem to be locked in the TM, and I have found nowehere how to unlock them in Lingo, so the translation agency had to unlock them for me.
Update: the incorrect tagging was actually generated by Trados who was trying to close some <mrk> tags when to Lingo's tastes they shouldn't have been closed.
Also, the translation agency has done something to the way they prepare files for translations and now segments are not locked anymore.
- Solena Le Moigne
Don’t worry, I’ll merge all those markups onto a single copy - Wade Nelson - techwhirl.com
Post Reply