Correct translation of field names

[julietiswriting]

Hi, I’ve spent a while looking but I can’t find anything similar to my question. I’m sorry if I’ve missed it. I’m trying to work out what needs to be set up in a Flare template to make translation easier. The situation would be where the software interface has already been translated and we were then wanting to translate the documentation.

I’m specifically trying to find out how a translation company would handle field names that appear in a document. For a normal sentence, they just translate the sentence in the best way. But, if it is a sentence that includes a field name, for example, Click the Build button, then they can’t use just any word for “Build” they have to use the name that that it was translated to in the software.
I’m assuming the translators would use the localisation file that is used to translate the field names to find out what the correct word to use is. But this is an assumption so it would be great if anyone knows if this is correct?

But my main question is about what you need to do in the document/template to make sure the translators/automatic translation tool identify those words?
Do you need to use a style that the translation tool can identify and know that it needs to treat that text differently? So a “field name” style? Or something else? And would that be enough?

And out of curiosity, would anyone know if the stage to translate those individual field names in the document can be automated or if it is manual? It would be a huge job to be done manually with lots of fields.

It seems as if this should be something common for software documentation, but I haven’t managed to find information online on it yet. Even on sites for companies that say they translate user guides, there is no mention of how they manage field names. I’m struggling to see how a translator could deal with it if they can’t easily see which are field names and which aren’t (except for field names being in italic or bold), and even if they notice how they’d make sure they use the correct term.

[ChoccieMuffin]

Just some random thinking here, because my current company doesn't localise, but in a previous lifetime I worked on a product that was localised, and we stored the software terms that were mentioned in a our user docs as variables. So when writing the source language, rather than just writing "click the Build button" you would insert the variable used for "Build" instead (and then format it in whatever way you normally format your software terms). When doing that, try to get the info direct from the software developers rather than just having a variable called, for example, "software_terms.Cancel" because there may be several different instances of the same word, used in different dialog boxes and therefore translated differently. You'd need to liaise closely with your softies to see how things are put together.

It's a long time since I worked for a localisation company and I know things have changed beyond recognition in that time, so you might get more up-to-date information from other forum members.

[doloremipsum]

We've had localisation plans in development for a while and haven't really tried them out yet, so take this with a grain of salt. What I am planning to do is load the translated strings from the software itself (i.e. fields, menu items, etc) into a Translation Memory and use those to automatically pre-translate some of the content in the document. Then I can hand the translator the translation files with some strings already partially translated and tell them not to mess with them.

This is partially a workaround because we are using a semi-crowdsourced translation service rather than a translation company, and therefore we have to manage everything ourselves. Any traditional translation company should be able to build their own translation memory if you hand them the translated strings from the actual software.

[julietiswriting]

Thanks both for your ideas. It's great to be thinking through options.

Hi ChoccieMuffin
I'd been thinking of the idea of using variables, and I think it would work really well for an interface with only a few field names. But the problem is what to do when there are hundreds of fields and so it would take a really long time to put them all in as variables. And also take a really long time to put the translated versions in as well, and would need rather a lot of organisation (that may not even be possible?) so that you'd know which variable applies to field names on which screen. Although maybe you'd have to trust/hope that the interface translation has translated all instances of the same term in the same way. But I'll admit that the idea of doing it this way with lots of fields would scare me.

Hi doloremipsum
I'd also been reading about how translators use translation memory, and this seems like a good idea. And it also means the translator will be using appropriate terms for the industry rather than more general terms that might not work. But I'm assuming this would mean all instances of a certain word would be translated into the word in the translation memory and if the term isn't being used as a field name you wouldn't necessarily want it automatically translated. But I suppose it would be easy enough for the translator to fix that when they got to it.
There's potentially a problem where the same field name isn't always translated in the same way, depending on where it is in the interface. Which is where a mapping file would work - but the mapping file would have to be used manually to check that and that's maybe not feasible to expect anyone to check each one. And so it might be better to just accept the translation memory approach.
The biggest issue I think is that the translator needs to be able to see which terms in the text are field names. Sometimes the field names are almost a sentence and at a quick glance, without being able to see what is a field name, the sentence might seem to not make sense or just some of it would be translated automatically using the translation memory. For example, Type the name in the Your name here text box.
I'd love to hear what happens when you try this out with the translator.

I'm hoping there's a friendly translator around who might know what they expect to receive when they have to do this. It feels like a big problem, but it must be something translators have to do every time they translate a user guide for software. I maybe also need to see if I can find some translator forums and go at this from the other direction!

[doloremipsum]

Ah, reading back I missed something important. We are planning on using translation memory, but for this we're also going to use a Term Base/Glossary. Similarly you can load these into translation software and it should flag terms which match those in the Term Base.

For now I've put together a Term Base with the most common menu items in our software and had it translated by someone who actually uses the software. Then (one day...) I will hand it to a translator for reference.

Do you use a special span class for your menu items/fields? That would probably be the best way of marking things.

[julietiswriting]

Hi doloremipsum, thanks for your reply. Yes, I think creating a style for field names is probably the best approach to at least have them obvious to a translator. And the translator should see them already translated in their version if I've provided the translations for the menu items.
There's quite a lot that feels like it could go wrong though! Some careful reviewing of the translated version will be needed!