Dealing with field names in user guides Thread poster: julietiswriting
|
|---|
Hello
I’ve had a search through the forums and I’m sorry if I’ve missed someone already asking my question.
I’m a technical writer and I’m looking to see what I need to set up to make things easier for translators! So I thought I’d come to you.
If it’s a user guide for software and so there are lots of field names in it, what do you need so that you treat the field names correctly? Should they have a style applied to them in my template? So, ... See more Hello
I’ve had a search through the forums and I’m sorry if I’ve missed someone already asking my question.
I’m a technical writer and I’m looking to see what I need to set up to make things easier for translators! So I thought I’d come to you.
If it’s a user guide for software and so there are lots of field names in it, what do you need so that you treat the field names correctly? Should they have a style applied to them in my template? So, rather than being italic or bold, they should be “field name” or something like that?
Also, how would you like to receive the list of translated field names if this has already been done? Are there any restrictions on format? For example, Word, Excel, Notepad, mapping file (not sure what the standard format would be for that).
I believe this list would go into the term base? If I’ve got that right? And would you expect to be verifying the terms as you go through, for example, in the software itself? Or would it be automatically translated from the list?
If I was getting something translated I’d obviously ask the translator. But this is more an idea to do everything we can at the beginning so that in the future it’s all set up as much as possible to facilitate translation.
Any tips from your translation side would be really gratefully received! ▲ Collapse
| | | |
One way to ensure the reader and translator know it's a field name is to use a specific font or style only for field names.
And yes, if the names are translated, TB entries with brief notes to the effect that they are field names would be helpful. The notes are important so the translator knows these terms aren't common words, as TB entries always have to be taken with a grain of salt, for example when a word can have different meanings and the TB entry only matches one meaning. Thi... See more One way to ensure the reader and translator know it's a field name is to use a specific font or style only for field names.
And yes, if the names are translated, TB entries with brief notes to the effect that they are field names would be helpful. The notes are important so the translator knows these terms aren't common words, as TB entries always have to be taken with a grain of salt, for example when a word can have different meanings and the TB entry only matches one meaning. This can all be maintained in a spreadsheet, which is easy to load into a TB. ▲ Collapse
| | | |
Thanks Thomas
The idea of identifying in the term base that they're field names is a useful tip. As some of those same words might be used elsewhere in the document but not as field names.
| | | |
I find it very encouraging that Juliet ask translators how she could make content more translator-friendly. I wish this attitude were more widespread to avoid back and forth checks, avoidable inconsistencies and sub-standard working conditions and translations.
[Edit: removed]
By "field name", I assume you mean "User Interface term" (UI term), ie. button labels, menus, options that are displayed in the program.
[Edit: Wrong assumption. removed]
[Edited at 2... See more I find it very encouraging that Juliet ask translators how she could make content more translator-friendly. I wish this attitude were more widespread to avoid back and forth checks, avoidable inconsistencies and sub-standard working conditions and translations.
[Edit: removed]
By "field name", I assume you mean "User Interface term" (UI term), ie. button labels, menus, options that are displayed in the program.
[Edit: Wrong assumption. removed]
[Edited at 2020-04-10 08:17 GMT] ▲ Collapse
| | |
|
|
|
| UI terms / field names | Apr 9, 2020 |
Philippe Etienne wrote:
By "field name", I assume you mean "User Interface term" (UI term), ie. button labels, menus, options that are displayed in the program.
That's not normally what a field name means, but UI terms are equally important. More often than not, the translator is not informed how such UI terms have already been translated in existing software, and as many deadlines are so short and the chain of command through one or more outsourcers is so long and slow that the client's replies often arrive after the deadline, many such translations end up with terms that may not match the actual software.
| | | | | The cart before the horse | Apr 10, 2020 |
Thomas T. Frost wrote:
That's not normally what a field name means,...
In context, I thought it was referring to UI terms. I don't know what it is, but nevermind, I'll remove the unrelated parts of my post.
Philippe
| | | | | Field name – reply | Apr 14, 2020 |
Thanks for your reply, Philippe. I’m glad you found my questions positive. Getting the documentation to match the interface can be difficult in the original language, so it’s obviously going to be even harder when it’s translated.
I obviously confused things a bit with my terminology, but you’re right, when I said “field names” I did mean UI terms.
I saw you removed the information in your post, but I’ll put it in again here as I thought it was really usef... See more Thanks for your reply, Philippe. I’m glad you found my questions positive. Getting the documentation to match the interface can be difficult in the original language, so it’s obviously going to be even harder when it’s translated.
I obviously confused things a bit with my terminology, but you’re right, when I said “field names” I did mean UI terms.
I saw you removed the information in your post, but I’ll put it in again here as I thought it was really useful, and it might be useful to someone else who has a similar question.
And if the program interface is translated and the translation checked and validated BEFORE anything else (translation of user guides, press packs, blog posts, online help, how tos...), even better.
By "field name", I assume you mean "User Interface term" (UI term), ie. button labels, menus, options that are displayed in the program.
Priority no.1: Ensure that 100% of UI terms are consistent with the UI glossary and throughout the style guide (spelling, phrasing, capitalisation...), so that all of them are understood as UI terms and consistency checks can be automated.
A style/bolding/italics or quotation marks/capitals for UI terms in a user guide is good practice for legibility. Moreover, applying a specific style can be useful at the translation preparation stage to generate "tags" that reference actual UI terms. Setting UI terms as tags in the user guide can help to ensure that consistency is maintained. Mostly, it's a means to decrease the cost of the
translation at the expense of the translator, but that's another topic. However, tagging can introduce other quality issues. There are other, simpler ways to ensure consistency: QA controls in "computer assisted translation software", what we call CAT tools, can do the job in a breeze without tagging, just using the UI "term base", or glossary. With a glossary properly used, translated UI terms will always be consistent with the interface actually displayed in the local language (screenshots or live use). With far less problems than tagged UI terms.
Now the "UI glossary": it references all UI terms in the program. Formats most commonly used are Excel and .csv, but CAT tools can generate term bases from a variety of other formats. Translators know that the UI term "%s %d remaining" may be found as "48 minutes remaining" in the user guide and search the glossary accordingly, that "Removable media in use" can be two "concatenated" strings, "Removable media" and "in use", appended and search accordingly, etc. Lastly, source and target text only isn't enough. "Display" can mean "Show" or "Screen", "Screen" can mean "Display" or "Filter", "Filter" can be a verb or a noun... And for each case, a specific and different translation. So, the more info about each UI term, the better, just in case context is lacking: the translator will decide what info in the glossary can be kept/discarded according to their own preferences and needs. ▲ Collapse
| | | | | UI terms / field names - reply | Apr 14, 2020 |
Thanks Thomas.
Yes, I can imagine it gets tricky! It sounds as if you're talking from experience. In my imagination on how this is all going to work it feels tricky, let alone in the real world.
I'm sorry I confused things with using the term "field names". It's maybe a term that is more used in technical writing/development than in translation discussions.
| | |
|
|
|
julietiswriting wrote:
I'm sorry I confused things with using the term "field names". It's maybe a term that is more used in technical writing/development than in translation discussions.
Microsoft's first definition of the term 'field' is: 'An area in a window or record that stores a single data value.' That's also how it's used in legacy programming.
The meaning of such a term shouldn't change just because the context is translation. That would just create confusion (as we've seen).
The actual field name is mostly not known to the end user, but in software manuals it's still important to use consistent style.
So what you really meant was UI element names, and as we all agree, this is a major issue in translation due to the common lack of communication.
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Dealing with field names in user guides | CafeTran Espresso | You've never met a CAT tool this clever!
Translate faster & easier, using a sophisticated CAT tool built by a translator / developer.
Accept jobs from clients who use Trados, MemoQ, Wordfast & major CAT tools.
Download and start using CafeTran Espresso -- for free
Buy now! » |
| | Trados Studio 2022 Freelance | The leading translation software used by over 270,000 translators.
Designed with your feedback in mind, Trados Studio 2022 delivers an unrivalled, powerful desktop
and cloud solution, empowering you to work in the most efficient and cost-effective way.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news
