Localization Question Regarding Folder Renaming

[pcalnan]

Forgive me if this question has been asked before but I'm looking for some assistance with a Flare project that we're having localized.

Currently, we used the folder naming convention of PRODUCT_LANGUAGE to keep our various language variants organized. For example, our source files are in the SUPERAPP_ENGLISH folder. Once the translated files come back, I intend on renaming the respective folders they're in to SUPERAPP_SPANISH, SUPERAPP_GERMAN, etc.

When I'm renaming the project folder name (this is the top-level one that contains the Analyzer, Content, Output and Project folders along with the .flprj file), how careful do I need to be? How many absolute pathname references are there as opposed to relative ones?

My presumption is that I'll need to do an external search-and-replace to find all of the files with _ENGLISH in the pathname and change it to _SPANISH (or whichever is appropriate) but I'd appreciate any comments, advice or suggestions anyone might have.

[LTinker68]

When I'm renaming the project folder name (this is the top-level one that contains the Analyzer, Content, Output and Project folders along with the .flprj file), how careful do I need to be? How many absolute pathname references are there as opposed to relative ones?

You probably can't rename the Analyzer, Content, or Project folders themselves because the Flare GUI and the app itself is set to look for various elements inside those folders. (The Output folder will just get recreated if you rename it something else.)

The parent folder they're in you can rename, but the "Recent Projects" list inside Flare will show that the project is missing because the path that you have indicated no longer exists. So if your help resides at C:\HelpProjects\ProjectA and you rename ProjectA to ProjectA_SP (for Spanish), then the "Recent Projects" list will show that ProjectA.flprj can't be found because it's looking for it in the ProjectA folder which no longer exists. However, the files within those folders are fine.

Is that what you were asking?

[pcalnan]

Heh, and why am I not surprised that Lisa comes to my aid (once again).

I wasn't thinking of renaming any of the subfolders as I don't want to mess with any of the project settings.

Fortunately, I'm not too concerned about the Recent Projects list as all I've worked on was the _ENGLISH original. When I get the translated files back, they will be exact duplicates of the original English-language files except that the content will be in other languages. The translation company isn't even going to change any of the filenames, thankfully.

Thus, the .flprj files in the localized versions will actually never have been opened or edited in Flare directly as they'll just be copies of my English originals. I'm assuming that I can just open those files and the translated projects will work (but that's a pretty big assumption, I'll readily admit).

It's to keep them separate and organized that I want to rename the parent folders to indicate the languages that they're in.

Thanks for chiming in, Lisa. You're as helpful as always and I'm glad to increase your post-count.

[LTinker68]

Thus, the .flprj files in the localized versions will actually never have been opened or edited in Flare directly as they'll just be copies of my English originals. I'm assuming that I can just open those files and the translated projects will work (but that's a pretty big assumption, I'll readily admit).

I don't have to translate my content (thankfully), but I believe the project settings can have a part in this. For instance, I don't think you can just open the Spanish project and build the output without also setting Flare to use Spanish. The language setting on the computer might have an effect, too. But again, I don't have to play in other languages, so I'm not sure how all that is tied together.

Are your translators also building the output when they send the project back, or are you going to compile the output yourself? Even if you use the command line option there may be language issues.

Hopefully someone else who does translations can chime in.

[doc_guy]

I also don't do translations, but if you aren't aware of Lingo, you should know that it was designed specifically to address the translation of a Flare project. You open the Flare project in Lingo, and the translators do all their work and they send back a new, localized project.

So in this case, you actually have separate projects; one for each localized version. This is a nice workflow going foward, because if content in the source changes, Lingo knows what has been translated, and what hasn't been translated, so you only end up translating those phrases, paragraphs, or topics that have changed. No going through the topics one-by-one checking for changes, or worse, paying to have the whole thing re-translated when much of the original content hasn't been modified.

Just thought I'd point out Lingo integration if you dind't already know about it. If I were localizing a Flare project, I imagine it would save a lot of time and money, especially when you got to version 2, when you are just updating some files.

Best of luck.

[pcalnan]

I don't have to translate my content (thankfully), but I believe the project settings can have a part in this. For instance, I don't think you can just open the Spanish project and build the output without also setting Flare to use Spanish. The language setting on the computer might have an effect, too. But again, I don't have to play in other languages, so I'm not sure how all that is tied together.

Good point, Lisa, and something I'll need to keep an eye on. I guess I'll trip over that particular landmine when I get to it.

Are your translators also building the output when they send the project back, or are you going to compile the output yourself? Even if you use the command line option there may be language issues.

No, they're translating the Flare project but not generating as we have multiple outputs (and they also don't have Flare themselves). When I receive the translated project files back, I'll need to open them (and hopefully that works) and then generate the different variants myself.

Thanks for the comments and I'll report back on my progress. Hopefully someone can learn from my mistakes.

[pcalnan]

I also don't do translations, but if you aren't aware of Lingo, you should know that it was designed specifically to address the translation of a Flare project. You open the Flare project in Lingo, and the translators do all their work and they send back a new, localized project.

Thanks for the tip, Paul. I actually have taken a look at Lingo and even recommended it to both my bosses and our translators. But the localization (like other things, *sigh*) is outsourced and our translation service doesn't have Flare, Lingo, nor any sort of inclination to pick them up as I believe we're their only clients (so far) to use Madcap products.

Hopefully that will change as I can see many benefits from integrating Flare with Lingo but we're breaking new ground for our company so hopefully the learning curve won't be too painful.

Cheers!

[doc_guy]

Now that Lingo will be supporting DITA, hopefully some of the localization companies will start to consider Lingo as a viable tool for translation, since Lingo will support all MadCap projects as well as any DITA project.

[GregStenhouse]

We are currently doing the same thing. I have found no issues copying the English to another folder, renaming it Spanish/French etc. All links appear to be relative.

Out of interest, if your translation company isn't using Lingo, what are they using? Are you exporting to Word then reimporting? FWIW we are using FrameMaker to author and translate, and import into Flare.

Cheers
Greg

[pcalnan]

We are currently doing the same thing. I have found no issues copying the English to another folder, renaming it Spanish/French etc. All links appear to be relative.

Glad to hear it, Greg. Thanks for the feedback.

Out of interest, if your translation company isn't using Lingo, what are they using? Are you exporting to Word then reimporting? FWIW we are using FrameMaker to author and translate, and import into Flare.

We've just sent them all of our Flare source files. The nice thing about the open architecture is that you can edit the files in pretty much any text editor, right?

The only localization they're doing is of the .htm topics in the Contents folder. We're also getting them to translate the character strings that will appear in the help UI and I'll have to manually insert those into the Skin and stylesheet files before generating.

As for what tools they're using, I'm afraid I don't know but it would be a lot easier on my end if they used Lingo.

Cheers, all!

[forfear]

We are currently doing the same thing. I have found no issues copying the English to another folder, renaming it Spanish/French etc. All links appear to be relative.

Glad to hear it, Greg. Thanks for the feedback.
The only localization they're doing is of the .htm topics in the Contents folder. We're also getting them to translate the character strings that will appear in the help UI and I'll have to manually insert those into the Skin and stylesheet files before generating.

As for what tools they're using, I'm afraid I don't know but it would be a lot easier on my end if they used Lingo.

It seems like you've got quite a bit of localization work to do, with Spanish and French. and i think its because you're all pretty good at what you do.

However, creating folders for Spanish and French and other languages in Flare...well...I've been there.

I replied to pcalnan in a private message. but here's the gist of it.
- Considering the amount of content that's being localized, i think there'll be future projects in store.
- Topics change but so do the use of snippets, variables, and styles used in your stylesheet.
- Justify the cost of lingo against a delayed localization schedule for all the language versions you have in store and dependent projects.
- Now add the cost of simply changing/updating one topic in the original project and see how a change needs to be replicated through to your TOC, Index, Hyperlinks, See Also links, Print outputs and multiply that by the number of language versions being produced.

I think Lingo helps to do a deeper level of translation work. I think there's a subscription based pricing model, but you could go for the full out version, they have promotions on for it...and you could use it on future projects...or pass it to your contractors, then take it back later on? especially as it seems your team is already using Flare a fair bit.

Never worked with localization contractors, and i imagine they are specialists with even more advanced localization assistance tools to help standardize the use of translated terms.

Imho the Madcap Lingo case study is not a pure marketing piece but a fair bit is based on our experiences. and we're not even a specialised translation house. Just a small bunch of inhouse hardworking training/doc folks.

If you can shell out a bit for the Madcap Lingo maintenance, there are future features which i think would make it better. I would have loved to have gotten that for a product like Madcap Lingo given its current and future potential. Its not perfect, but very easy to justify if you've been doing a bit of inhouse translation regularly enough, for even small teams which do help docs regularly and are in it for the long term.