Use Lingo even if translator uses something else?

[LindaW]

I need to have my WebHelp translated to French Canadian, and then later on to a few other languages. The translator that the company uses does not have MadCap Flare or Lingo. I think it still makes sense for me to use Lingo to package the files to send to the translator? I'm not 100% clear on how that works, but I want to get the benefit of being able to keep track of what has already been translated. We will need to update the translations at least once a year. So, would that be my workflow:
1. load the files into LIngo
2. send the files in Lingo to the translator
3. when I receive the files back from the translator, load them from Lingo into Flare

Does this work? Will the translator be able to receive and send Lingo files?

Does anyone have experience with this process?
Thanks,
Linda

[RamonS]

So the workflow would be Flare > Lingo > translate > Lingo > Flare. While that is the usual flow I don't think you will be using Lingo for anything. You might as well send the Flare project directly over for translation and then use the translated project as a new Flare project. If you want to keep in the Flare ecosystem you may see if the translator is willing to use Contributor instead, but I'd be surprised if he/she agrees to that. I'd send the project over (not the compiled output) and assume that the plumbing stays in place. Some files such as index keywords or the ToC may need some special treatment.

Does your company have any customers in Canada that would be willing to do the translation for compensation? In my experience having a subject matter expert do this yields the better results that they know the terms of the trade better than even a good translator who knows nothing about your industry. If that is not an option make sure that your company gives the translator at least some general training about the product. I've seen translations that were linguistically excellent, but still were bad, because terms were translated incorrectly using words that make no sense in the given context. I think that someone who knows what it is all about does a better job, even if the writing style may not be excellent. For that you can still hire an editor to remove the rough edges.

Just my 2 ct.

[LindaW]

Thanks - that's great advice. The translator that the company uses is the one that translates the screens for the application - but, still, I don't know if they know our industry terminology.

I just want to be clear on what will happen if I just use Flare, and leave Lingo out of the loop. I want to be sure that my translation is tracked in MadCap, to avoid duplication in translations later on. My WebHelp is relatively new, so I am constantly publishing updates. We will update the translations at least yearly, maybe more often, and eventually into multiple languages.

If I don't use Lingo, will I have a way to keep track of what has already been translated, into which languages, and which sections need to be translated? Would I have to do that with Condition tags in Flare?
Thanks,
Linda

[techwriter31]

One problem we've had with Lingo is that we've found it doesn't always correctly indicate whether or not the content in the file has changed. (We've had cases where content has changed, but Lingo indicates that it hasn't, and vice-versa.)

You should be able to package the files using Lingo and send them to your vendor with no problem. When you package the files though, it will automatically add a bunch of random characters to the file names (these characters are only in the packaged file names, and don't show up when you reimport the package into Lingo). Our translation vendor didn't really like the random characters. If your translation vendor doesn't have Lingo, it shouldn't matter. They'll just have to be sure to zip up the translated files using the same folder structure, file structure and zip file name as the one you sent to them. You'll then reimport the zip file back into Lingo and export the Lingo project to a Flare project. You'll generate the output in Flare, and I'm guessing you'll want to send the output back to the vendor for them to proof. I could see this getting a little complicated with more than one round of translations for a particular revision though...

If you already have Lingo, I'd highly recommend using it to store your translation memory, especially if you'll be switching vendors often. Your translation memory should definitely be considered an asset, considering how expensive translations are.

[Sharpras]

Here's a question for RamonS: you recommend to Linda that

I'd send the project over (not the compiled output)

. However, her translator does not have Flare or Lingo. Being new to translation, I'm wondering how the translator can use the Flare files, do all the translation, including TOX, index, snippents, etc. Can any translator do the translation without Flare tools?

PS. We will soon be needing tranlation into Simple Chinese.

[techwriter31]

Hi Sharpras,

Will you be outputting to PDF for your Simplified Chinese translations? If so, there's a problem with how Flare handles parenthesis:
http://forums.madcapsoftware.com/viewto ... &sk=t&sd=a

[RamonS]

Here's a question for RamonS: you recommend to Linda that

I'd send the project over (not the compiled output)

. However, her translator does not have Flare or Lingo. Being new to translation, I'm wondering how the translator can use the Flare files, do all the translation, including TOX, index, snippents, etc. Can any translator do the translation without Flare tools?

PS. We will soon be needing tranlation into Simple Chinese.

The Flare files are XML (text) files in the end. As long as the markup is not disturbed there should be no problem. Translating the output only will require copying and pasting the translations into the Flare project, which is a lot of work and rather difficult if it is a language the TW does not understand.

The only other idea I have is to see if MadCap 'rents out' licenses for Lingo. Buy a license that expires after six months and give that to the translator. I think that would be a reasonable candidate for SaaS.

[DocuWil]

Hi,

About 1 year ago I created a document named Infologic Translation Instructions.

In the Introduction I wrote:

Infologic Nederland B.V. uses single sourcing to provide customers with documentation.
Single sourcing means writing a piece of text (topic) that can be reused for different kinds of output,
like PDF or Webhelp and for different documents.
A great feature is that making updates are very easy; that is, only at one point the update will be made
and all outputs contain the same update.
Furthermore variables and conditions are used which created a way to easily change process names,
titles, versions, revisions and so on.
When documentation has to be translated by a 3rd party it is important that also in this situation single
sourcing is used to match the changes of the original document.
For that purpose Infologic provides the translator with a series of files in the English (UK) language
together with a TMX file.
TMX stands for Translation Memory Exchange and is a standard within the translation community.
After the translator has translated all material it needs to be packed and send back to Infologic.
Next Infologic produces the translated output for PDF, Webhelp and if needed other output.
However, Infologic never takes any responsibility for the translated text.
To understand the context of the files to translate, the PDF document in the English language is send
together with the package.
This document describes how the translator can proceed.

In this document I made use of the open source translation tool OmegaT. I did test it from English to my own language Dutch.

If you like to get the complete PDF document then please send me a private message with your email address. In the subject: Infologic Translation Instructions

[Sharpras]

Thanks all, for the information.
I'm not currently outputing the Simple Chinese to PDF, but good to know about the parenthesis.
A time-limited license of Lingo sounds--maybe too good. Great idea. I guess you are also saying that any XML editor can be used to edit the content files as long as one knows to find and change snippets and index items without messing up the markup.
I'll also look into OmegaT.

Roger

[Fedja]

Many (if not most) translators worth their price-per-word quote use a CAT - Computer Assisted Translation tool. These are database-driven and commonly include an XML editor. I'm most familiar with SDL Trados, which is one of the biggest market players in that field, so I'll comment on that, though I'd like to point out that other solutions work in much the same way.

Lingo lets you export your project, and you receive a folder packed with HMTL files and a TMX-standard database. Note, your initial database is likely to be empty.

The HTML files
The files are topic files in a single folder. I'm not sure how much code stripping Lingo does in the export. If there's much leftover variable and design code in the strings, you may want to use an experienced translator to build you a Trados .ini file which defines the kinds of code that the CAT should "lock" or ignore. This lets any translator you'll use in the future focus on the content only, which makes for happier translators lower cost of outsourcing over the long term.

The TMX database
The database is a source-target single string database of all your documentation. CAT tools use it to auto translate repetitions and suggest possible translations on the fly when sources only differ slightly. This is the main product of your translation process, and the most valuable resource in your localization operation.

The first time you send out your project, the translator will return your database (you should insist on this) with the files that he translated in the CAT XML editor. This database is going to be extremely valuable for any other similar project you have in the same language pair. You can always send your translator the small files such as the TOC and list of keywords to translate manually, and you can copy paste the strings to Lingo yourself.

Bottom line, if your content is in any way technical, make sure you use a process that's TMX compatible and that you use translators who work with CAT tools. It can reduce your translation costs as much as 50% on the 2nd iteration of the project and as low as 80% once the project is in its 5th, 6th cycle. It'll also dramatically reduce your turnaround time for subsequent translations of corrections and expansions of your content.

[SolenaLeMoigne]

The translators of our translation agency work with Trados. When they ship us a translated bundle, they also send the translation memory.

Open the Lingo project, load the translation memory and the bundle, and watch out for the following pitfalls:
- the keywords tags are not in front of the word they're supposed to tag (at least, they're in the same segment, so the Index works out OK in most cases),
- the snippets tags usually end up at the very end of the segment, giving interesting and incorrect results when generating the target language documentation,
- the Xrefs tags are either completely removed or re-translated in the text and in the CSS giving, again, interesting results.
According to our translation agency, the MadCap tags don't show up in Trados, so the translators just don't see them and can't know what they're doing to them.

Anyone else experiencing the same issues? Any suggestions as to how to make my days a tad less interesting?

[RossF]

According to our translation agency, the MadCap tags don't show up in Trados, so the translators just don't see them and can't know what they're doing to them.

Trados can be made to work with the tags by making edits to the html ini file (or making a new ini file for madcap html files).
You have to add a definition for each custom madcap tag, and set whether it is to be included in or excluded from a segment.

Several agencies I have dealt with know enough to ask for the ini file, but if they aren't familiar with Flare's code, its a large job for them to create one. A working ini file is quite difficult to come by for this reason... few people have the CAT tool and have Flare and know enough about madcap tags.

[SolenaLeMoigne]

You're entirely correct, RossF. We've been building one, piece by piece and I have even suggested to the translation agency to sell it back to SDL

[alt_jennifer]

I know I'm a little late to the ballgame here, but...

SDL already has custom filters for MadCap Flare files, for use in Trados Studio 2011 (and maybe 2009). They're not automatically included, but they're available in the SDL Exchange (the translators should hopefully know what that is).

I don't use those filters, so I can't say how good or bad they are. We long ago created our own custom filters that we use for all translation projects.

One important thing to point out about sending your entire Flare project to a company or translator that doesn't have Flare --- while it's true that the files are XML, and that a good translation agency should be able to customize a filter, not all can do that. ALSO, the translatable content in a Flare project is not only in topics, glossaries, TOCs, etc. There are many unique file types that an unexperienced vendor would have no clue needs translation. Not to mention, they wouldn't understand the overall Flare folder structure. And since they don't have Flare, they would have no clue how to determine which files are actually in use or not. So sending them the whole Flare project when they don't know Flare is potentially a problem. You would need to send along explicit instructions on which files/folders need translation. In general, I think it's easiest and safest to go with a vendor who already knows Flare very well. No worries then about getting the right files translated or messing up the code.