Using Lingo with global project linking - Best practice

[MAF]

Bonjour everyone,

I am currently looking at translating several of our Flare (V11) projects and I tried out a few things with Lingo (V9). Since my projects are all based on global project linking, I am trying to decide what the best workflow is to get the best of single sourcing while keeping the translation process nice and simple.

So far, I tried two different workflows which both have their pros and cons:

Workflow A:
For each project, I import it straight into Lingo, translate it and export it back into a new translated Flare project.
Pros:

• - The workflow couldn't be simpler!

Cons:

• - I need to deactivate manually the "Auto-reimport before Generate Output" in the translated flare project before generating the translated targets. If I don't do this, my original untranslated global project files will replace my translated files, including snippets, CSS, etc. This is a pain because any change for example in a CSS in the global project means going through the complete lingo process again... On all projects
  - I need to apply several changes to the translated project before generating the translated targets. For example, I need to change the publish destinations so that the translated project does not replace the original
  - This workflow is (really) bad for single sourcing: all my global files go through the translation process for every project and that doesn't seem right
  - I couldn't find a way to exclude some content (unused topics or internal comments for example) that I don't want to be translated

Workflow B:

• 1. I translate my global project using Lingo and export it into a translated global project copy
  2. from my original project, I create an export using a target which excludes content I don't want to translate (e.g. internal comments, copyright snippet page from the global project, etc.).
  3. I translate the exported content by importing it into Lingo and exporting it back into a temporary Flare project
  4. I create a translated project and set it up to automatically import both the translated copy of the global project and the translated exported content (e.g. *.html, *.png, etc.)

Pros:

• - this workflow separates project specific content from global project content and ressources. For example, if I need to make a minor change in my global CSS, I only need to update all my translated copies of the global project and recompile all my project, without opening Lingo
  - I have quite a lot of control on content I want to translate or not using the export fonction in Flare. For example I can translate docs chapters by chapters, which is basically how we work at the moment
  - some global content is translated only once, which is the aim of single sourcing

Cons:

• - Sacrebleu ! Does it really need to be that complex?

At the moment, I cannot make up my mind on which workflow to use and I know that once I've chosen a path, I'll have to stick with it and not regret it. Surely I am not the only one translating projects using global project linking. How did you solve this for your projects ? Am I missing something obvious in the Flare/Lingo process and make my life for too complicated ?

Thanx in advance for any feedback on this.

[MAF]

Hi and bonne année everyone,

Am I the only one translating Flare projects with global project linking?

If you have any idea on this subject, I am still interested, otherwise I guess I'll have to make a decision with no help from my friends.

[Catcha]

We are trying to figure out the same thing here. We do have global project linking and no experience with translating Madcap at all.
We just started out and trying to translate our first projects with trados2015

I was hoping for some support.
So sorry I Cannot help you But I do seak the same answers.

[ChoccieMuffin]

Hi.

Disclaimer on/
I don't use Lingo, but I do use GPL fairly heavily, so my suggestions are based just on GPL rather than Lingo.
Disclaimer off/

Can you do the following:

Translate all the projects that are imported using GPL
STRIP all projects of anything that is imported.
Translate the stripped project.

I would imagine (but could be very wrong!) that your translated, stripped project can be instructed (in the .flimpfl files) to import the translated projects, so you can then have an entire translated project.

Just a thought, you'd have to have a try to see if I've missed out some vital piece of Lingo guru-ness.

Good luck!

[MAF]

Thank you ChoccieMuffin, what you describe is actually what I implemented a few weeks ago and it works. After thinking all this over, I actually reached the same conclusion as you that the global project HAD to be translated. The workflow I ended up using is the following :

Workflow C:

• 1. I translate my global project using Lingo and export it into a translated global project copy
  2. I translate my project using Lingo and export it into a translated Flare project copy. During this phase I "manually" ignore all files which come from the global project
  3. I manually change things in the translated project, the most important ones being the import .flimpfl file, the target names and the publication destinations

Pros:

• - this workflow separates project specific content from global project content. For example, if I need to make a minor change in my global CSS, I only need to update my translated copy of the global project and recompile all my translated project... without opening Lingo
  - global content is translated only once, which is the aim of single sourcing

Cons:

• - The main problem is that I have no way of knowing what content requires to be translated in my project because project specific content is mixed with imported global content. When sending content to translation, I must be careful not to send global content. Having said that, since I have followed the excellent advice on Flare's forum to prefix my global file names with GBL_, this part is not such a problem for me.
  - Every time I make a change in the project and translate it, the export from lingo overwrites my manual changes in the translated project and I have to go through step 3 each time. This is a known Lingo annoying behavior which I hope will be on day improved (Please dear MadCap, could it be possible to "update the output" in Lingo in the same way we "update the input")

This workflow is my best shot so far, hopefully it can help some of you.

Thank you again for your help !!