About Bundles

So what is the benefit of using Lingo as a "middle man" in this translation effort? Why not just use Word, Flare, or another tool for the documentation and then send those files directly to the translator? You can certainly send a translator raw files and bypass Lingo altogether, but this only works well if your translator is very familiar with those kinds of files. And it is highly unlikely that your translator is an expert at Flare and understands all of the different types of files that make up a Flare project. Therefore, the best solution is usually one where the translator uses Lingo for the translation work or when you (the content developer) use bundling in Lingo to manage the translator's work on your end, incorporating the translated files back into Flare (or whatever tool you are using).

• Ensure That All Files are Translated One of the best reasons to use bundling is that Lingo tells you exactly what files need to be translated so that you do not accidentally miss some. This might not be necessary when translating a simple Word document. But if you have a Flare project that requires translation, there are likely many different types of files that are easy to forget about—files such as skins, glossaries, search filter sets, and many more. If you translate the Flare project in Lingo, the File List window pane shows exactly what needs to be translated, so there is no guessing. But if you try to translate that same Flare project in a third-party tool, it can be extremely difficult to determine which files require translation.

• Generate More Accurate Estimates Another good reason to use bundling is the statistics feature in Lingo. The statistics report lets you see exactly what has been translated and what still requires translation. See Computing Statistics.

  This can positively affect a translator's estimates. For example, if you hire someone to translate a Flare project, the initial estimates given by the translator might be too low because several files may have been accidentally missed. After discovering the extra files, the translator needs to adjust the estimates.

  In addition, you can use the report to see how many matches were found in translation memory (TM) for the segments. This is important because it is much less expensive for translators to use existing translations in a TM database than to produce new translations.

• Avoid Rework When translating files, it's important for the translator to keep the folder structure that you have in place. Otherwise, the result could be lots of broken links and missing information. With a Lingo bundle, you can be assured that the folder structure is maintained throughout the process.

By using bundling in Lingo, you can avoid these issues. The translator will receive all of the files requiring translation work, and only those files. This allows the translator to give you a more accurate estimate for the necessary work, and for you to see the statistics yourself. When you receive the files back from the translator, you can use Lingo to verify that everything was translated and nothing was left behind.

Bundling is different than most of the other features in Lingo because the individual using this feature in Lingo is typically the content developer, rather than a translator. The following steps show how it works:

1. Create Lingo Project (Content Developer) The content developer creates a Lingo project based on the project or files that require translation. See Creating New Projects.
2. (Optional) Create/Import Translation Memory (Content Developer) You can create a new translation memory (TM) database for the project and import a Translation Memory eXchange (TMX) file from the translator. Your translator's quote should take into account previous translations from the TMX file (which makes translation work less expensive than translating brand new segments). You can view statistics (Step 6 below) on the project to see how many translations from the TMX file match segments in your source documents. See About Translation Memory, Creating a Translation Memory Database, and Importing TMX Files.
3. Prepare and Send Bundle (Content Developer) In Lingo, the content developer bundles the necessary files in the project. You can bundle all files or only selected files. To do this, open the File List window pane, select the appropriate files, and click the Prepare Translation Bundle button . Then send the bundle—which is either a ZIP file (if the translator will be using a third-party tool) or an LIPRJZIP file (if the translator will be using Lingo). This bundle file consists of the content files requiring translation, and can also consist of translation memory databases or termbases. See Preparing Translation Bundles.

4. Translate Content, Send ZIP or LIPRJZIP File (Translator) Using a third-party tool or Lingo, the translator performs the translation work, puts the completed files into a ZIP or LIPRJZIP file, and sends it back to the content developer.

   Note: Translators must return a bundle in the same file format as the original bundle they received. If you sent the translator a Lingo project file (*.LIPRJZIP), you should receive an LIPRJZIP file back from the translator. Likewise, if you sent the translator a ZIP file, should receive a ZIP file back.

5. Merge Completed Bundle (Content Developer) The content developer reintegrates the translator's work with the Lingo project (by clicking the Merge Completed Bundle button in the File List window pane). See Merging Completed Bundles.

6. Ensure Completeness (Content Developer)  There are a few ways that the content developer can ensure completeness of the translations.

   • Statistics You can select File>Compute Statistics. This displays a statistics report showing detailed information for the project and each file. Using this report, the content developer can see exactly how many words and segments were translated. See Computing Statistics.
   • Reports In addition to running a statistics report, you can also run quality assurance (QA) reports to find any discrepancies between the source and target segments in your project. To do this, you can select File>Project QA, then select the type of QA report you want to run. Using these reports, the content developer can find errors the translator may have missed, such as formatting or punctuation inaccuracies, misuse of the termbase, or repeated segments.
   • Status The File List window pane lists each content file and various information for each. One of the columns in this window pane is named "Status." This column displays the translation status of each file (e.g., Untranslated, In Progress, Completed, Reviewed, Approved). The translation status can be set manually, or when certain actions are performed, the status is set automatically. After a translator returns a bundle and you merge it back into a Lingo project, the status of each file is updated, depending on the situation. If the translator only partially translates a file, the status changes to "In Progress." If the translator finishes translating all segments in a file, the status changes to "Completed." If the translator returns the file untouched, the status remains "Untranslated."
   • Review You can export translated content to a MadCap Contributor review archive file (LIREV) and send it to a third party for review. See Sending Translated Content for Review.
7. Export Translated Projects (Content Developer) After ensuring that everything is completely translated, the content developer exports the Lingo project to the necessary file(s) (e.g., a new Flare project, a new Word document). See Exporting Translated Projects.

example

Bob is a technical writer for a small company that does not have in-house translators. He uses MadCap Flare to create his English documentation and then sends that project to an outside vendor to translate the content into Spanish. The translation company uses SDL Trados, so when the translator looks at the Flare files, he's not sure which files need to be translated, how long it will take, or what it will cost. Bob also doesn’t know how much translation work is involved.

Therefore, Bob's company buys Lingo. Using Lingo, Bob creates a new project based on his Flare documentation and installs a TM database. In Lingo he bundles the files requiring translation and emails that ZIP file to the translator.

Using SDL Trados, the translator imports the ZIP file and translates the content. The translator puts the translated files back into a ZIP file—just like the one received—and returns it to Bob.

Bob receives the email and saves the ZIP file to a folder on his computer. In his Lingo project, Bob selects the "Merge Completed Bundle" option and browses for the ZIP file received from the translator. Lingo takes the bundle, extracts the files, and merges them into the Lingo project.

Bob then selects File>Compute Statistics, which displays a report reflecting detailed information about the translated files. The report is designed to warn Bob of any files that the translator may have missed, and possibly consistency problems.

In addition, Bob can look in the File List window pane to see the translation status of all of the files.

If necessary, Bob can inform the translator of any files that were not translated and request a new, updated ZIP file from the translator. After all of his files have been successfully translated, Bob exports the Lingo project to a new Flare project. So now he has two Flare projects—the original English project, and the new Spanish project.