How are you translating / localizing your Flare projects?

[Phlawm53]

I'm curious what work flows Flare users have in place to translate / localize their Flare projects.

I am contract tech writer who recently convinced my current client to use Flare as its documentation authoring environment. The client now wants to translate the U.S. English Flare project into French. More languages are likely to follow.

I've read about Madcap Lingo and visited Lingo's Madcap Forum. Lingo looks to me like a reasonable and reasonably cost effective way to deal with the issue of translation / localization.

But I'm curious what other methods may be available. If you're localizing your Flare projects:

- What file formats are you submitting to your translation / localization vendor?
For example, Word, FrameMaker, XML, XHTML, or...?

- How to you package files for submission?
For example, one big file, multiple per-topic files, or...?

- What automation does your localization vendor employ?
For example, Trados, or...? And have you ever encountered revision-level incompatibilities between submitted files and the vendor's automation product?

- When translated files come back, how do you get that file or files back into a Flare project?
For example, import, copy-and-paste, or...?

- How many manual steps, if any, does your localization work flow impose?
For example, clean up of translated or imported files, script development and use, or...?

I say "non-Lingo", but would welcome any comments about that product's usability and usefulness.

Cheers & thanks,
Riley
SFO

[RamonS]

Those are all valid questions, but may be difficult to answer. It all depends on the translation agency and how much money you want to spend. The casual translator (who may not ask much money) may be better suited with a Word document, professionals typically can work with a wide array of formats and deliver an equally wide array. If you want them to use a specific tool and they do not have it then you typically would need to buy it and pay for training, but that also depends on the company you are dealing with.
If you want to go the Lingo route you may ask MadCap sales about translation service companies that bought Lingo and offer that as a service.

[Phlawm53]

If you want to go the Lingo route you may ask MadCap sales about translation service companies that bought Lingo and offer that as a service.

That's a a very good idea. To be continued…

Cheers & thanks,
Riley

[williamgwilliams]

I am facing a situation similar to Riley's. The translators won't all have Flare licenses, so I need to figure out how to get them files they can edit, and, more challengingly, how to incorporate their translations back into a Flare project.

For example, I can output to a monolithic Word target (I've been doing this for reviewers, so they can edit and add comments, then I manually incorporate these). But for an entire translated file, it would be a heck of a task to paste and format the translated files--and for the languages I'm not familiar with, this would be extremely risky.

Any suggestions (aside from making them get a Flare license) for a least painful approach?

Thanks,

- Willie

[Phlawm53]

For example, I can output to a monolithic Word target…

Word's world-famous unreliability, document-defacing incompatibilities between successive versions, and clumsy user interface makes me nervous any time I'm compelled to use the product for anything but the smallest ad hoc writing tasks (in fact I prefer OpenOffice 3.x).

Given that, the idea of relying on Word to round-trip translated Flare projects flat out terrifies me…

Cheers & thanks,
R

[ccardimon]

"document defacing" -- love that phase.

[RamonS]

For example, I can output to a monolithic Word target…

Word's world-famous unreliability, document-defacing incompatibilities between successive versions, and clumsy user interface makes me nervous any time I'm compelled to use the product for anything but the smallest ad hoc writing tasks (in fact I prefer OpenOffice 3.x).

Given that, the idea of relying on Word to round-trip translated Flare projects flat out terrifies me…

Cheers & thanks,
R

I read ya and fully agree. I'm an avid OOo user and tester as well. I use it at home as well as here at work and never ever came across anything I had to do an OOo couldn't do (although, importing MSO docs better would be a plus). I asked several times that MadCap adds ODF support to Flare, but as a .NET showcase company and gold-pressed latinum partner of Microsoft the embrace of open standards that are truly open and actually work (not like OOXML) may be too much to ask.
The only reason I mentioned Word is that pretty much anyone with a working PC can somehow deal with that file format. And if not, there is still the old, but fine RTF.

[williamgwilliams]

Dumb of me to have mentioned the Word target--that was only for reviewers wanting write (edit) capability.

But my main question is, once translators have translated the files (using some editor that handles XHTML) and localized the images, can one simply create a new (say "Japanese") project, stick all the files there (with their old filenames (but now Japanese content), copy over the TOC and Master Layout files, etc. from the "English" project, and compile a "Japanese" help system? Or is that likely to require massive cleanup (much of which would be impossible for me to detect, not reading Japanese)?

And for the translators themselves, if they don't have Madcap, and therefore can't preview and compile, are there going to be things they can't do, like link the images? I can imagine that there would have to be a lot of back and forth, where they send me the files to compile, then I point them to the output to proof, then they update their files and send another set, and so on. This could be more expensive than getting them licenses with which they can compile it until it's ready, and just send back a finished help system. But they of course would have to learn Flare.

Anyone dealt with this?

- Willie

[ccardimon]

Dumb of me to have mentioned the Word target--that was only for reviewers wanting write (edit) capability.

It wasn't dumb. I still output to Word when people ask me to. Word is far from obsolete.

[Phlawm53]

Anyone dealt with this?

- Willie

You've summarized several of the key issues that had inspired my original post.

My hope was and is that someone who has been through a complete Flare localization cycle or two will eventually help all of us find our way through the maze.

I'm also not opposed to the use of Lingo to handle many of the localization issues you describe. I'd just like to understand Lingo in the context of other possible localization work flows.

(And as ccardimon pointed out, Word is a perfectly valid Flare target, although it may not be an ideal files exchange medium, especially for translated files…)

Cheers,
R

[RamonS]

But my main question is, once translators have translated the files (using some editor that handles XHTML) and localized the images

Localized the images in a sense of creating new screen shots that fit in the existing layout? I wouldn't count on it. Sure, a service company gladly does that for you but you will likely pay up for each screen shot.
For these cases take a look at the concept of screen portraits here:
http://techwritetips.wordpress.com/2006 ... portraits/
It is more work upfront, but it will save you a bunch of work and money and time when translating!

[williamgwilliams]

I went through the Lingo "movie"--which I found very encouraging--and have a couple of questions about Lingo.

• - Does a Lingo project have a Compile function (like Flaire's)? That is, as you are translating files, can you compile the help system to see what the target language output looks like as you proceed?
  - In a Lingo project, when you are translating a file, is there a Preview function (like Flare's)? That is, can you see what the output for the individual file you are translating will look like via a Preview (or some such) button?
  - When you export the completed (that is, translated) Lingo project back into Flare, does it become a kind of "target"? That is, if I now have a Flare project that has both the original English and now an "imported" Spanish Lingo project, do I compile each language's help system as a target (e.g., the primary target for English and a secondary target for Spanish)>

Thanks,

- Willie

[RamonS]

As for the "targets" the answer is no. Lingo creates a brand new project that is independent from the source project. This may be tedious going forward compared to a project that has all translations and you use conditions to separate the different languages, but that is likely to be true only when dealing with two or three languages. After that the conditioning will become so complicated that you potentially end up with a mix of languages in a target. There really aren't that many advantages from having one project. The two that come to mind is sharing of common content (language independent artwork for example) and versioning. Both can be overcome when having some discipline using multiple projects.

For the other questions, I am not sure, I'd have to take at Lingo which I don't have available right now. Did you search the Lingo help file?

[williamgwilliams]

I don't mind that it creates a separate Flare project for the translated files. In fact, that probably makes it easier for me to not mix things up when I commit the output systems to our source control system. (You might ask, "Why do you keep *output* files in source control?" It's because that's how we get the help into the product builds.) So we'll probably keep each language version under a "locale" directory (en-us, es-es, etc.) and I'll just copy the "WebHelp" directories there.

As for preview and compile (build), I didn't find those in the help, but did a pretty quick search. I guess, assuming the export-to-Flare process is quick, one could export the project to Flare and do the compiles and previews in Flare.

Your comment about "language independent artwork" reminds me of another questions: How *are* images handled? I assume when you point to the Flare project as you create the Lingo project, it includes all the image files in the files it loads into the Lingo project. Do you just overwrite these image files with localized versions? In the help I see a topic for "Translating Image Callouts," but nothing about the images themselves. I guess, for the images in which I added "annotation" in the image itself, I should instead have used callouts. Oh well, next time.

[RamonS]

The callouts as far as they were made with Capture can be translated. The base image itself needs to be redone because it is a bitmap and Lingo doesn't know where text is and how to insert the translated text cleanly. Therefore, use screen portraits and callouts (If necessary).
As far as I know Lingo copies the image files over, but even if not it would be a one time manual process.

[kkelleher]

I just got a proposal from our translation vendor (Simultrans, with whom we've worked for several years) for our new help system (source = Frame imported into Flare; target = WebHelp), so I thought I'd share what we found out, even though Lingo doesn't seem to fit into our workflow.

- What file formats are you submitting to your translation / localization vendor?

Our vendor recommends that we translate the Frame source files rather than the Flare project or webhelp target. This allows us to use the translated Frame content in other projects (part of our single sourcing strategy), and allows us to output the content to multiple targets (though we don't have plans to take advantage of this).

in this workflow, you have a choice about who builds and tests the final, other-language targets (either your own team or your translation vendor). We're probably going to have our vendor do it.

- How to you package files for submission?

We zip up the Frame source and FTP it to them. We'll separately zip the English-language project so they can use it to develop the other-language projects and targets.

- What automation does your localization vendor employ?

They use Trados, but we haven't yet completed a translation cycle, so I don't know if we're going to get false positives from the analysis. My gut tells me we will.

- When translated files come back, how do you get that file or files back into a Flare project?

For our workflow, the process is to create new Flare projects that import the translated Frame files, but we're likely to have the vendor handle that for us.

- How many manual steps, if any, does your localization work flow impose?

i suspect there will be some, but we're too early in the process to be able to say.

Thanks,

Kristen

[Phlawm53]

For what it's worth, I'm still facing my Flare localization problem. And it's getting worse -- a deadline is approaching and the translation vendors aren't especially knowledgeable or helpful.

I'd prefer to use Lingo, but it's been correctly observed that not many localization companies use that tool. And as a contractor / consultant, it's problematic to get a customer to embrace the idea that it will pay its localization vendors' tools and training cost; this problem does, of course, also apply to employees as well as contractors…

Most of the translation companies my customer knows about claim that Word is their files-exchange medium. I'm concerned that round-tripping Word files will present a huge and ongoing set of manual cleanup and fix-up tasks. For example, x-refs are sure to get broken, variables, on and on.

Setting Word aside for the moment, I'm very familiar with FrameMaker and so appreciate that its styles and behaviors are more consistent than Word's; FM files might therefore provide a better exchange medium. But insofar as I've recommended the use of Flare as a way of eliminating the FrameMaker+SomethingElse duad required to generate usable online help from FM binaries, it would therefore be a total Madcap loss if the Flare localization work flow compelled the purchase of FrameMaker, too.

So, I'm still keen to hear from anyone who is successfully translating production size and production quality Flare projects.

Is anyone? Surely I'm not the only Flare user who's having this problem?

Cheers & thanks to all,
Riley

[Andrew]

Does MadCap have any translators they recommend for Lingo translation (or at least, translators who support Lingo)?

[Phlawm53]

Does MadCap have any translators they recommend for Lingo translation (or at least, translators who support Lingo)?

Andrew:

I got a couple of names from my Madcap sales rep. I won't pass those names on this forum, but will instead suggest that you -- and anyone else that needs help -- also contact Madcap and ask for help with your localization problems.

I'm actually quite nervous as I type this. I've invested about two months developing multiple print/online projects after convincing my current contract customer to move away from Word (ugh!) and to Flare 6 as its documentation authoring tool. And indeed, Flare does many of the things this customer needs done; the fact that I like working with Flare is a pleasant byproduct.

But if the translation / localization of Flare projects becomes a separate major mountain that needs climbing from figurative sea level, the whole thing may come apart pretty quickly. I really hope that isn't going to happen…

Cheers, thanks, & hope this helps,
Riley

[GregStenhouse]

So, I'm still keen to hear from anyone who is successfully translating production size and production quality Flare projects.

Is anyone? Surely I'm not the only Flare user who's having this problem?

Hey Riley

We are using FrameMaker to translate our Flare Projects, and it is relatively successful. We are not round-tripping though, our English is also authored in FrameMaker and imported into Flare to create the help (1-way). I do think round tripping will work, as long as you are prepared to drop some Flare features like glossaries, popups, drop downs, snippets etc. FrameMaker works well for deltas too, as it comes with a handy compare feature.

As an aside, as long as your translation vendor has Trados (pretty standard amongst agencies), they will not have to have FrameMaker or edit your frame files directly. Trados comes with a tool called s-tagger for FrameMaker, which essentially converts the frame files to a format Trados can use (via MIF).

Feel free to contact me directly if you need to know more or want to see examples of our translations.

Cheers
Greg

[alt_jennifer]

I am actually a Flare operator at a translation agency. We translate Flare projects all the time, and can handle many different types of requests. We have translated Flare projects using Lingo and not using Lingo. (We do more of the latter.) We've done very simple projects, and we've worked on very complex projects, with dozens of linked in (imported) sub-projects. I can't speak for other companies, of course, but here are our answers to your questions:

What file formats are you submitting to your translation / localization vendor?

- Our clients send us the Flare projects, zipped, and a copy of their finalized English outputs.

How to you package files for submission?

- Simply zip up the English project as is, in its final version.

What automation does your localization vendor employ?

- We do use a CAT tool (SDLX, primarily) as a translation environment for our linguists, since none of them have Flare or Lingo.

When translated files come back, how do you get that file or files back into a Flare project?

- We take care of all the integration work into Flare, so that our final deliverable to the client is finished, localized Flare project.

How many manual steps, if any, does your localization work flow impose?

- We have our initial File Prep stage, where we import the Flare content into our translation tool. (Note that it goes right from Flare into our tool, and does not pass through Word!!). The content is then translated, edited, and reviewed by the client if desired. Following that, we have integration into Flare and cleanup work as necessary there. The output is then proofed/QCed by a linguist, and we make corrections based on their feedback. Then the final Flare files and outputs are delivered to the client.

Hopefully this information helps. There are indeed few translation companies out there that understand Flare very well, and we like to consider ourselves one of them. I actually quite enjoy Flare, which I've learned on the job, but have developped quite a knack for in the localization arena. Let me know if you have any more questions -- I'd be happy to help clear things up for you.

[ccardimon]

Thanks for chiming in, Greg and Jennifer. I was hoping someone out there had these things figured out. Glad this "stuff" actually works.

[williamgwilliams]

Thanks, Jennifer, for the specifics and the general confidence-that-it-can-be-done booster!

When your group (operators and translators) gets a Flare project to translate, how do you create the project to localize? That is, say you are sent Project A to translate into Japanese and Spanish. I would assume you would somehow make two copies of the project, one for the Japanese trnaslators and one for the Spanish translatoer. This way, you could load (however you do it, but that's another subject) each into your CAT tool, translate it, and bring the translated topics (and images) back into the Japanese and Spanish Flare projects. In fact, I would think you would do this multiple times, so you can compile and preview the files in Flare. (You can probably preview individual topics in the CAT tool, so maybe the compile is the thing you would do periodically in Flare, to QA that the translations are going well.)

So you would send the Japanese and the Spanish projects back to the client, right?--no need to send them the original (English) project, since they already have that. But how does one make a copy of a Flare project? I don't see a "Copy Project" function. Do you import it? I suppose you could simply, in Windows Explorer, copy the entire directory tree and rename the directories, say, Project_A_ja_jp and Project_A_es_es. But then you've got project files (.flprj) files with the same name. Can one simply rename the project files (appending ja_jp and es_es)? Or will that break back references to the project file names elsewhere in the project?

Thanks,

- Willie

[LTinker68]

I suppose you could simply, in Windows Explorer, copy the entire directory tree and rename the directories, say, Project_A_ja_jp and Project_A_es_es. But then you've got project files (.flprj) files with the same name. Can one simply rename the project files (appending ja_jp and es_es)? Or will that break back references to the project file names elsewhere in the project?

You can rename a .flprj file, so copying the entire parent folder (the one containing the analyzer, content, project, and .flprj file) and then renaming the .flprj file will work. So if your parent folder is called ProjectA and it has projecta.flprj, then you can copy and rename the parent folder to ProjectA_Spain then rename the project file to projecta_spain.flprj. Everything within ProjectA_Spain is relative to that parent folder, so nothing is broken when you rename the .flprj file. Don't know if that's what Jennifer does for her localization, but that is how you can create a copy of a project.

[Eric Lachance]

I'll chime in also here, we have a project that is currently being localized into 6 different languages by our translation company. We simply zip & send them the original English project, and they return us 6 zip files with a complete, localized, ready-to-output projects each in their own separate folder.

Internally (at the translator's) it's fairly easy: most major translation tools can read XML straight out of the box, and the company can apply special rules so that only what needs to be translated is, and the rest is left untouched.

Setting up the first project was (and still is) a tedious process. As the translator is sending us a first language for us to review, we notice things that aren't correctly done (tags that aren't translated, project files that need to be modified, etc) and email them the corrections to make. One of the last things that we requested (and the translator agreed to do since it's easy with their tools) is to modify the Destination files and the project file itself to reflect the new language (going from en to fr-CA and ja , for example), so that the WebHelp is in the correct language and outputs to the correct location in our network drives.

So when we receive the final, reviewed and approved translations, all I need to do is unzip the file, and run a small flare automation batch file that builds and publishes the projects using a batch target (which includes webhelp and PDF outputs). That's it - unzip and double-click. We never actually touch the localized files, we simply overwrite them with new versions when they are given to us and re-build them.

In terms of changes to the original project, if I create a new topic and change things around in the english version, I simply zip and send them a new one. Their tools can easily create a "diff" file with all my own changes, so their translators can just make those changes and send us a new zip files with the new localized projects.

That's the way it should be with your translator, unless you're dealing with a company too small to have "real" translator tools. In that case I would strongly suggest finding a company that uses Lingo.

Cheers!