I'm new to Madcap and internationalization. Could someone tell me what's the difference is between (1) using Lingo together with a translation vendor and (2) sending files generated by Madcap Flare to a translation vendor?
Thanks.
Purpose of Lingo
-
RamonS
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Purpose of Lingo
Lingo creates a new Flare project for the translation, your vendor might not do that and return (mangled) HTML files that need further work done before being ready to be ported into Flare.
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U

Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
-
Nita Beck
- Senior Propellus Maximus
- Posts: 3672
- Joined: Thu Feb 02, 2006 9:57 am
- Location: Pittsford, NY
Re: Purpose of Lingo
Then again, some translation vendors can handle Flare projects perfectly fine and will return a clean, translated Flare project from which output can be generated. (I realize that I'm not answering the poster's question. I'll tap a Flare expert I know at a translation company who maybe will weigh in.)
Nita

RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
-
alt_jennifer
- Propeller Head
- Posts: 57
- Joined: Mon Mar 08, 2010 12:33 pm
- Location: Fayetteville, NC
- Contact:
Re: Purpose of Lingo
Hello,
I'm the localization manager (and Flare specialist) at a translation company (Nita was referring about me). The route you use depends entirely on the translation vendor you're working with. (Sorry in advance for the long post!)
Ramon S is right that some translator or translation agencies do not have the expertise to be able to handle Flare files reliably, and they might not be able to tell what needs translation and what doesn't. For vendors like that, sending them files exported from Lingo might be easiest. (Although even some translators might not do well with Lingo files.) However, that means that you are in charge of any adjustments that may need to be made in the exported, localized Flare project yourself. For instance, you may need to change the fonts used, the list styles used (is "a,b,c" doesn't work for that language). There could issues with variable placement (depending on which version of Lingo you use), or general tag placement errors by the translator, etc. If you have the generated output proofed (as you should), then you would have to implement corrections yourself. All this can sometimes be daunting if one has never worked with translations before.
Some people do opt to send the generated outputs (i.e., Word file or WebHelp) to a translation vendor for translation. This does work, especially with translators who lack technical expertise, but then you lose the benefits of single-sourcing. If you have an update, the entire Word file has to be reprocessed, as opposed to only the topics with changes. So this approach isn't usually preferred.
However, if you work with a company that has high expertise in Flare, then you can simply send them your finalized English Flare project, and they will return a finalized translated project, with finalized outputs too. This is what we do at our company, and it works very well. We know which text needs translation; we know how to filter the files for translation; we know all the steps needed post-translation to ensure a high-quality product; and we implement any necessary proofing changes. It means minimal effort and worry on your part when you work with a vendor you can trust to handle your Flare project.
As for the difference between working with Lingo vs. not, it all depends on whether or not your vendor does all the Flare work or whether you do it. As mentioned above, it's usually better to let an expert at both translation and Flare do this work, to ensure the best quality product.
Working with Lingo:
- You can get an idea of the scope of translation work. It gives you a word count and file count, although the word count may legitimately differ from the word count done by a translation vendor, since translation vendors usually use other translation tools that have their own word counting. In general, most translators will not work in Lingo, since our industry's standard translation tools have been around for decades and have perfected a lot of things that Lingo is still relatively new at. So a translator's word counts may not match Lingo perfectly, but they should be in a similar range.
- You can track updates in Lingo, although it will not tell you if there is a difference in a file's source code or if something has been deleted. So it's not a perfect indicator of updated files but it can give you an idea of new translations needed.
- You can view and manage your Translation Memory in Lingo, which (to me) is it's greatest benefit for clients. Translation vendors can always provide clients with these TMs, but most clients have no way to view them. Lingo provides that.
- Re-exporting a Flare project from Lingo could reverse any corrections that had previously been done to the localized Flare project. As mentioned above, there are usually language-specific corrections to do after exporting from Lingo. If you do a set of updates and re-export the Flare project, those corrections are lost and must be redone.
Working with a Flare expert for translation:
- A translation vendor who is an expert in Flare will be able to identify everything that does or does not need to be translated, and can customize the scope based on requirements you provide (such as "only translate content for this output" or " don't translate anything with this condition").
- Such a vendor will have customized filters to process all the Flare files without messing anything up, and their tools will have accurate word counting.
- We can compare previous and current versions of the Flare projects for a thorough and accurate scope of updates. Only the files that have changed would need to be processed, translated, and proofed.
- We hold on to our previously localized Flare projects, so we can reuse all unchanged files in updates, to avoid extra rework.
- The best recommendation is to use a translation vendor who is MadCap recommended, like we are, since they will know how to handle your Flare projects the best.
I know that all of this information – the processes, the options, the risks – can be a bit overwhelming at first. If you'd like to discuss any of this further, I'd be happy to talk with you.
I'm the localization manager (and Flare specialist) at a translation company (Nita was referring about me). The route you use depends entirely on the translation vendor you're working with. (Sorry in advance for the long post!)
Ramon S is right that some translator or translation agencies do not have the expertise to be able to handle Flare files reliably, and they might not be able to tell what needs translation and what doesn't. For vendors like that, sending them files exported from Lingo might be easiest. (Although even some translators might not do well with Lingo files.) However, that means that you are in charge of any adjustments that may need to be made in the exported, localized Flare project yourself. For instance, you may need to change the fonts used, the list styles used (is "a,b,c" doesn't work for that language). There could issues with variable placement (depending on which version of Lingo you use), or general tag placement errors by the translator, etc. If you have the generated output proofed (as you should), then you would have to implement corrections yourself. All this can sometimes be daunting if one has never worked with translations before.
Some people do opt to send the generated outputs (i.e., Word file or WebHelp) to a translation vendor for translation. This does work, especially with translators who lack technical expertise, but then you lose the benefits of single-sourcing. If you have an update, the entire Word file has to be reprocessed, as opposed to only the topics with changes. So this approach isn't usually preferred.
However, if you work with a company that has high expertise in Flare, then you can simply send them your finalized English Flare project, and they will return a finalized translated project, with finalized outputs too. This is what we do at our company, and it works very well. We know which text needs translation; we know how to filter the files for translation; we know all the steps needed post-translation to ensure a high-quality product; and we implement any necessary proofing changes. It means minimal effort and worry on your part when you work with a vendor you can trust to handle your Flare project.
As for the difference between working with Lingo vs. not, it all depends on whether or not your vendor does all the Flare work or whether you do it. As mentioned above, it's usually better to let an expert at both translation and Flare do this work, to ensure the best quality product.
Working with Lingo:
- You can get an idea of the scope of translation work. It gives you a word count and file count, although the word count may legitimately differ from the word count done by a translation vendor, since translation vendors usually use other translation tools that have their own word counting. In general, most translators will not work in Lingo, since our industry's standard translation tools have been around for decades and have perfected a lot of things that Lingo is still relatively new at. So a translator's word counts may not match Lingo perfectly, but they should be in a similar range.
- You can track updates in Lingo, although it will not tell you if there is a difference in a file's source code or if something has been deleted. So it's not a perfect indicator of updated files but it can give you an idea of new translations needed.
- You can view and manage your Translation Memory in Lingo, which (to me) is it's greatest benefit for clients. Translation vendors can always provide clients with these TMs, but most clients have no way to view them. Lingo provides that.
- Re-exporting a Flare project from Lingo could reverse any corrections that had previously been done to the localized Flare project. As mentioned above, there are usually language-specific corrections to do after exporting from Lingo. If you do a set of updates and re-export the Flare project, those corrections are lost and must be redone.
Working with a Flare expert for translation:
- A translation vendor who is an expert in Flare will be able to identify everything that does or does not need to be translated, and can customize the scope based on requirements you provide (such as "only translate content for this output" or " don't translate anything with this condition").
- Such a vendor will have customized filters to process all the Flare files without messing anything up, and their tools will have accurate word counting.
- We can compare previous and current versions of the Flare projects for a thorough and accurate scope of updates. Only the files that have changed would need to be processed, translated, and proofed.
- We hold on to our previously localized Flare projects, so we can reuse all unchanged files in updates, to avoid extra rework.
- The best recommendation is to use a translation vendor who is MadCap recommended, like we are, since they will know how to handle your Flare projects the best.
I know that all of this information – the processes, the options, the risks – can be a bit overwhelming at first. If you'd like to discuss any of this further, I'd be happy to talk with you.
Jennifer Schudel
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
-
alt_jennifer
- Propeller Head
- Posts: 57
- Joined: Mon Mar 08, 2010 12:33 pm
- Location: Fayetteville, NC
- Contact:
Re: Purpose of Lingo
By the way, you also might find this thread/post helpful:
http://forums.madcapsoftware.com/viewto ... 13&t=13316
http://forums.madcapsoftware.com/viewto ... 13&t=13316
Jennifer Schudel
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
Re: Purpose of Lingo
This might also help:fchan wrote:I'm new to Madcap and internationalization. Could someone tell me what's the difference is between (1) using Lingo together with a translation vendor and (2) sending files generated by Madcap Flare to a translation vendor?
http://www.madcapsoftware.com/assets/LingoWorkflow.pdf
I'm in the same boat as you, trying to figure out how to manage all this.
{Gripe}
I have to say it is typical that the Lingo Help, and help in general, offers nothing like the above overview. Lots and lots on the obvious, nut and bolts stuff, but little in the way of high-level concepts that help a user make more strategic decisions. The assumption being that everyone reads the marketing material?
{/Gripe}