Localization: translating topic file names

[simona]

Having had a long, hard look at my first output from Lingo, I realized that quite a few things have not been translated, e.g.

- topic file names (*.htm, we generate WebHelp output)
- RelationshipTables
- concept links

I dare say that our U.S. customers will not be impressed if we ask them to open htm-files with funny-looking foreign names. So how can I translate the file names of all topics? Is this not done in Lingo? What have I overlooked?

[alt_jennifer]

Hi Simona,

I work at a translation company, and specialize in Flare/Lingo projects.

Typically speaking, filenames are not translated. This is because it causes a whole lot of rework in the project -- all the topics have to be relinked to each other, and to the TOC. Granted, Flare will do most of that for you, as long as they're done inside the Flare project, but it does cause risk. Also, there are many special characters in foreign languages that are not well-supported in URLs. For example, if we were to translate a filename into French, we shouldn't use any accented characters, so it would look strange anyways to French eyes. In the grand scheme of things, it's just easier to leave filenames in English. If they need to be translated for special requirements, they can be. However, as far as I know, Lingo does not account for that, so you would have to get the translations from the translator in a bilingual table in Word (English filename on left, translated filename on right) and then copy/paste the new filenames inside Flare. In any regards, you would be doing this in the French Flare project, not in the English one, so I wouldn't think your US customers would see the translated filenames.

Relationship Tables themselves do not have to be translated. They are nothing but links to other files. However, if the contents of a relationship table still appears in English in the generated output, it is due to the topic headers themselves. The Relationship Table will pull the name of the topic from (1) the <title> or (2) if there is no <title>, then from the first header tag it sees (<h1>-<h6>) or (3) if there is no <title> and no header tag, from the filename. So check to see if the topics that appear in English in the relationship table in the generated output have either a <title> or a header tag. If not, just add one in (with the translation in place), and regenerate the output. It should be fixed. I've seen this happen when the author used a <p> tag instead of a header tag, and had no <title> either. We just copied the text from the <p> tag into the <title> tag, and it worked.

Concept keywords are available for translation in Lingo. They appear in a file named Concept.liconceptmap. However, in 99% of the Flare projects I've seen, the concept keywords are never visible to the user. They're just used as behind-the-scenes links. So as long as that is the case, we just don't translate them. There's less risk of running into linking errors that way. However, it certainly is possible to use concept keywords in a way that makes them visible. If that's the case, then that Concept.liconceptmap file simply needs to be translated. I suspect that Lingo would then update all instances of these keywords for you, so you don't have to do any updating yourself. But I've never needed to translate them in Lingo before, so I'm not positive.

If however, you are referring to the list of files under a Concept Link, then it’s the same problem as Relationship Tables. Or, if you’re referring to the “See Also” (etc.) text by Concept Links, then that is controlled either in the Language Skin (.fllng), the stylesheet, or even in the topic. (Occasionally I might see a special attribute in the concept link’s tag, in the code, that specifies “See Also” or some other text. I’m not sure whether Lingo pulls that in for translation or not.) Flare will first look to the topic code, then the stylesheet, then the Language Skin, so I’d look in that order too.

I hope this information helps. If you need more details, let me know!

[Nita Beck]

Jennifer, you are such an asset to the forums! I always learn so much from your thoughtful explanations.

[simona]

Hi Jennifer,

thanks so much for the long and informative reply, it is great to be able to benefit from your vast experience! Additionally, I have received a response from the MadCap support wizards, stating pretty much the same thing.

Concepts: I have found Concept.liconceptmap when MadCap support told me to switch from folder view to a view without folders in Lingo. Then Concept.liconceptmap becomes visible \o/. In this project I am the sole tech writer for DE and EN, working in Flare and Lingo simultaneously to define the proper workflow, which is why I noticed that I had somehow managed to translate 1 concept name, but not the other. You are probably right that no user of our WebHelp would have noticed that, but it puzzled me a little. Still, I consider the issue of concepts solved now.

As for relationship tables I now see that I probably will not have to translate them, but the file names still worry me a little. You see, the source project is in German (DE). I create all topics in German first w/ German file names, because our primary market is in Germany and it is my mother tongue. However, I then translate the project into English (EN-US) for our U.S. customers, too. While it is true that renaming all files is probably unnecessary, leaves a lot of room for error and would cost extra time, I have noticed that - within WebHelp - the file name of the currently opened page appears in the browser URL field. It contains stuff like:

#topics/a_tasks/benutzer_anlegen.htm%3FTocPath%3DHow to's (tasks)|_____1

where "benutzer_anlegen" is the German file name for "create user". I would rather save the time and not bother translating this, especially after your reminder as to how error prone this would be, but I do know that our US co-workers and customers would dislike it if such cryptic and foreign stuff was visible. If there was any way to make this disappear I would probably use it.

I guess I'll run a few more tests to see if the rel-table links to concept, ref_table and task come out okay within the topics in WebHelp and also have a closer look at the skin, as you suggested.

The good news is: Despite all these initial problems of defining the workflow and project setup (which cost me much more time than I had expected, to be honest), our Flare/Lingo combination is already working pretty well. I ended up having more projects than anticipated and there are quite a few steps to do for each content update, but it is all slowly coming together

Thanks and best regards,

Simona