Regarding reference material for a help manual Thread poster: transatlantic
|
|---|
Hello all,
My partner and I are due to translate an online help manual for a software program.
We've been sent an inhouse glossary, as well as a list of GUI translations and alerts.
However the latter aren't complete. In 90% of cases, it's completely unclear what terms the actual program codes and user interfaces in English use. Now, we could take a jolly good guess, based on our knowledge of the field and the supporting documentation, but surely, somewher... See more Hello all,
My partner and I are due to translate an online help manual for a software program.
We've been sent an inhouse glossary, as well as a list of GUI translations and alerts.
However the latter aren't complete. In 90% of cases, it's completely unclear what terms the actual program codes and user interfaces in English use. Now, we could take a jolly good guess, based on our knowledge of the field and the supporting documentation, but surely, somewhere along the line something will go wrong, i.e. what it says in the manual won't match what it says on the program interface.
I've asked for access to the English language version of the program, but have been told that it's not available.
This isn't the first time this has happened with an agency. And I feel like it's strange that I have to ask for the info. Or am I missing something here? Should I actually be able to figure out what terms and abbreviations the program itself uses on my own? Any ideas as to this , and how to best communicate with agencies in these cases, would be greatly appreciated.
JMA ▲ Collapse
| | | | | just in case .... | Dec 27, 2005 |
... it's unclear - I don't have any intention of 'guessing'. If I can't get the necessary information, I'd rather just refuse the project.
JMA
transatlantic wrote:
Hello all,
My partner and I are due to translate an online help manual for a software program.
We've been sent an inhouse glossary, as well as a list of GUI translations and alerts.
However the latter aren't complete. In 90% of cases, it's completely unclear what terms the actual program codes and user interfaces in English use. Now, we could take a jolly good guess, based on our knowledge of the field and the supporting documentation, but surely, somewhere along the line something will go wrong, i.e. what it says in the manual won't match what it says on the program interface.
I've asked for access to the English language version of the program, but have been told that it's not available.
This isn't the first time this has happened with an agency. And I feel like it's strange that I have to ask for the info. Or am I missing something here? Should I actually be able to figure out what terms and abbreviations the program itself uses on my own? Any ideas as to this , and how to best communicate with agencies in these cases, would be greatly appreciated.
JMA
| | | | Luca Tutino 
Italy
Member (2002)
English to Italian
+ ...
| Compile a list of terminology/questions | Dec 27, 2005 |
Failing everything else you are actually left with educated guesses. Ideally in this case you should compile a list with all your terminology guesses/choices (possibly a table including references for all places of occurence in the original files) and submit it to the client.
I guess this could be a problem if you did not think about it during the negotiations. However it should be possible to discuss the matter with the agency.
Take into account that this is a frequent... See more Failing everything else you are actually left with educated guesses. Ideally in this case you should compile a list with all your terminology guesses/choices (possibly a table including references for all places of occurence in the original files) and submit it to the client.
I guess this could be a problem if you did not think about it during the negotiations. However it should be possible to discuss the matter with the agency.
Take into account that this is a frequently occurring situation due to the way software is mostly produced, and not because you are supposed to magically remedy it.
[Edited at 2005-12-27 19:42] ▲ Collapse
| | | | | thanks for reply | Dec 27, 2005 |
Hi Luca,
Yes, I've already started writing list of such terms/codes. However, this could really increase our workload.
If they're writing the English version, they could at least say so from the get go, rather than just sending a glossary with incorrect translations and no information.
More will be revealed.
Thanks for answering the post.
Slightly grumpy,
JMA
Luca Tutino wrote: Failing everything else you are actually left with educated guesses. Ideally in this case you should compile a list with all your terminology guesses/choices (possibly including all place of occurence in the original files) and submit it to the agency. transatlantic wrote:
Hello all,
My partner and I are due to translate an online help manual for a software program.
We've been sent an inhouse glossary, as well as a list of GUI translations and alerts.
However the latter aren't complete. In 90% of cases, it's completely unclear what terms the actual program codes and user interfaces in English use. Now, we could take a jolly good guess, based on our knowledge of the field and the supporting documentation, but surely, somewhere along the line something will go wrong, i.e. what it says in the manual won't match what it says on the program interface.
I've asked for access to the English language version of the program, but have been told that it's not available.
This isn't the first time this has happened with an agency. And I feel like it's strange that I have to ask for the info. Or am I missing something here? Should I actually be able to figure out what terms and abbreviations the program itself uses on my own? Any ideas as to this , and how to best communicate with agencies in these cases, would be greatly appreciated.
JMA
| | |
|
|
|
| queries, beta sw, strings with ID | Dec 28, 2005 |
Translation of the documentation often takes place while the sw itself (original anf localized) is not final yet.
Apart from Luca's suggestion of keeping a list of queries or of terms you used but would need to be checked in context, I think you should also make sure that the client _does_ require the GUI terms in the doc translated at this stage.
If you cannot get a copy if the sw as reference (ideally, both original and semi-localized beta!), maybe you can ask to get ... See more Translation of the documentation often takes place while the sw itself (original anf localized) is not final yet.
Apart from Luca's suggestion of keeping a list of queries or of terms you used but would need to be checked in context, I think you should also make sure that the client _does_ require the GUI terms in the doc translated at this stage.
If you cannot get a copy if the sw as reference (ideally, both original and semi-localized beta!), maybe you can ask to get screenshots, or to be put in contact with someone who can answer your queries promptly as they arise.
Also, what format have the GUI strings been supplied to you? It may be possible to get them in a slightly more intelligible format, including for instance a string ID which may be revealing as far as context is concerned (from the string ID it is sometimes possible to tell what menu or dialog box a certain string appears in, and find related strings).
All the best,
Roberta
[Edited at 2006-01-11 13:29] ▲ Collapse
| | | |
That's the thing, we were only pulled on board to translate the online help manual - all the GUIs should have been or are being translated. However, so far, little to none of the material we have been sent is relevant to what we're translating. Additionally, of the few terms that do come up in our text, many are are inconsistently and incorrectly translated.
We're trying to get screenshots now. Hopefully this will all be resolved next week.
Thanks for the moral and pra... See more That's the thing, we were only pulled on board to translate the online help manual - all the GUIs should have been or are being translated. However, so far, little to none of the material we have been sent is relevant to what we're translating. Additionally, of the few terms that do come up in our text, many are are inconsistently and incorrectly translated.
We're trying to get screenshots now. Hopefully this will all be resolved next week.
Thanks for the moral and practical support.
JMA
Roberta Anderson wrote:
Translation of the documentation often takes place while the sw itself (original anf localized) is not final yet.
Apart from Luca's suggestion of keeping a list of queries or of terms you used but would need to che checked in context, I think you should also make sure that the client _does_ require the GUI terms in the doc translated at this stage.
If you cannot get a copy if the sw as reference (ideally, both original and semi-localized beta!), maybe you can ask to get screenshots, or to be put in contact with someone who can answer your queries promptly as they arise.
Also, what format have the GUI stings been supplied to you? It may be possible to get them in a slightly more intelligible format, including for instance a string ID which may be revealing as far as context is concerned (from the string ID i is sometimes possible to tell what menu or dialog box a certain string appears in, and find related strings).
All the best,
Roberta
▲ Collapse
| | | | Vito Smolej
Germany
Local time: 13:41
Member (2004)
English to Slovenian
+ ...
SITE LOCALIZER | this is an ongoing process... | Jan 7, 2006 |
... and I'm sure there's programmers out there doing one more final touch to the product. And they will for sure be doing it for some time coming.
So the only way to go is to keep the structure flexible, via IDs as suggested and, if at all possible, via some mother of them all dynamic, persistent structure, where all these items have or will eventually have their place. Actually the system people should be able to produce this structure (on an ongoing basis) for you to hang the in... See more ... and I'm sure there's programmers out there doing one more final touch to the product. And they will for sure be doing it for some time coming.
So the only way to go is to keep the structure flexible, via IDs as suggested and, if at all possible, via some mother of them all dynamic, persistent structure, where all these items have or will eventually have their place. Actually the system people should be able to produce this structure (on an ongoing basis) for you to hang the information meat on, while still having the freedom to add to it, to change it and eventually to complete it. If they don't have it, well, there's always a next revision coming sometime (sg).
Again, you're just a part of the process (actually the sad point is your job is on the critical path and what's more the last one on it). You can't be (much) better because of others, and if you do your job properly, you can't be worse than the whole either. You're firmly stuck into the system, whatever its pluses and minuses.
btw, if the product is OK, who needs documentation or a help file (just hinting at the future tar pits).
regards
smo
[Edited at 2006-01-07 23:07] ▲ Collapse
| | | |
Thanks for the replies everyone.
I followed your suggestions. Without access to the software, and with an incomplete and incorrect glossary, we just translated it as best we could and additionally delivered a long list of suggestions.
Plus, I kept trying to get some clear info on what stage the client was at... For example, if they haven't finalized the GUI, maybe we should just translate it properly, and at least they've have some good suggestions for the field names,... See more Thanks for the replies everyone.
I followed your suggestions. Without access to the software, and with an incomplete and incorrect glossary, we just translated it as best we could and additionally delivered a long list of suggestions.
Plus, I kept trying to get some clear info on what stage the client was at... For example, if they haven't finalized the GUI, maybe we should just translate it properly, and at least they've have some good suggestions for the field names, etc. But then we'd need more info/access to the program. It was really difficult to get a clear answer.
Now the second part of the project has come in, and a second lot of missing or mistranslated GUI terms. I managed to talk to one of the client's project managers, who told me that, in fact, they're aware of the issue. However, the GUI was poorly translated six years ago and they don't have the money to overhaul it. And that we should just use the incorrect terms throughout the help manual.
It's a worry, bacause often the translated GUI terms not only do not reflect industry standards, but in some cases actually contradict accepted definitions...
I feel like a bit of a klutz here, I really thought that if they said the GUI translation would be supplied, they would supply it and it would be correct.
How could I make sure this never happens again, without simply foregoing this type of project?
Is it even ethical to continue with the project? (With the concern that if we pull out, we won't get paid for what we've done?)
Apologize for excessive lengthiness.
regards,
JMA ▲ Collapse
| | |
|
|
|
Luca Tutino
Italy
Member (2002)
English to Italian
+ ...
| You might consider pulling out... | Feb 4, 2006 |
If the client knowingly insist that you should use wrong translations, and these are so bad that force you to produce a meaningless translation, you might seriously consider pulling out. Hopefully this will result in new budget decisions...
They will have to pay for what you have already done, if they use it in any way.
[Edited at 2006-02-04 22:31]
[Edited at 2006-02-04 22:32]
| | | | | wishful thinking... | Feb 6, 2006 |
Luca Tutino wrote:
u might seriously consider pulling out. Hopefully this will result in new budget decisions... [/quote]
I pulled out of a project only once because I felt the circumstances were not allowing me to do a decent job of it.
Budget decisions were not reconsidered, I guess they just found someone to do the job instead of me, within the same constrains.
Ok, this is just one case, but I'm seeing more and more decisions made on budget principles alone...
Maybe I'm just suffering from winter blues, but right now I do not have a very optimistic view
Roberta
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Regarding reference material for a help manual | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
| | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
