In order to allow more consistent translations, done by several translators in parallel, we’re going to add a translation glossary, per client.
This glossary will tell how to translate special terms to different languages and will be used for all the client’s projects.
Let’s start with an example.
iPhone golf-instructor application
Supposing a client is creating an iPhone application that teaches how to play golf. That client will have a multilingual website, an iPhone application, customer support translation and some small texts to translate from time to time.
It would be nice (for us) if we could get everything to translate at once, fully documented and explained. In practice, it doesn’t work this way.
First, we’ll get the iPhone application’s texts with minimal documentation. The translator will ask questions and get to know the application.
Then, a few weeks after, the website will follow and then customer support calls will trickle in.
It means that several translators will need to work on the same project. One on the iPhone application, another on the website and whoever is free first on small translations that follow.
In order to produce consistent translation, the translators will need to have a glossary that tells how to translate phrases used repeatedly. Each client would have a glossary, used for all projects and accessible by any translator working on that client’s projects.
How the shared glossary would work
Both the client and translators would be able to add phrases to the glossary. Clients can create the glossary entries and translators can add both the entries and their translation.
For instance, the Spanish translator would probably add phrases like ‘trainer’, ‘club’ and ‘swing’. Then, when the client starts translating the website to Spanish and the word ‘trainer’ appears, the (possibly other) Spanish translator would already see that it should be translated as instructor.
Later, when the client also decides to go French, the French translator would see that ‘trainer’, ‘club’ and ‘swing’ require special attention and would first add their translations to the glossary.
Glossary everywhere
Glossary entries would be used for any kind of project done by ICanLocalize. No matter what we’re translating, if the text includes a phrase that appears in the glossary, the translator would see its explanation and previous translations.
Translation Assistant (our translation software) will scan the glossary automatically and would automatically highlight phrases found in the glossary. It would also let translators create new glossary items and consult the client about the meaning of key phrases.
Glossary and Search Engine Optimization
One of the most important things to notice when translating is search engine optimization (SEO). Even if you’re not translating a website, what you translate will most likely appear in some website somewhere.
It’s important to check what people are looking for and translate according to that. This would be good for search engine optimization and, generally, for getting more business.
When you begin translating, make a list of the main phrases in your application, that people might use to find you through.
The new glossary would be the perfect place to document these phrases and discuss their best translation with your translators.
What do you think? Any ideas for what a glossary should do?
Hi, Glossary per client is a great idea. Hopefully, there won’t be a clash of opinions! Translators have sometimes cherished ideas what should be a particular translation, and maybe would prefer their own idea to what is in the glossary. However, you may add that in a project for a particular client, if a glossary is there, nobody will ARGUE! and will have to use what is there. Eva
I agree with Eva. If we have a glossary per client, we do not have to go back to past translations to find out how it was translated. Also, glossary can be categorized per field such as computer, engineering, agriculture, medical, etc. so one word can have different interpretation depending on the subjects. For example, “bridge” in English can mean an actual bridge over the river but it can also mean a type of dental treatment or a part of eye glasses, etc.
Could work well, but (like Eva) I worry there may be differences of opinions – also some need for QC – if the word/phrase in the glossary is incorrect , and everyone uses it, the clients are not going to be very happy! Overall, it seems it might create less work for the translators, but more for you Amir!
I like the idea. I assume that the creation of such a glossary would involve several steps – the final one could be for the Client’s staff to approve it. You could also make a grading function for translations, like in Google.
This looks good. To combat the problem of ‘bad translations’, I wonder if there would be any benefit in implementing a ‘rating’ system, whereby users (such as subsequent translators) could rate the word/translation combination on how effective they felt the word was. Perhaps this could help other users come to their own conclusions on which word to translate to. I guess this might be difficult if the client only uses the one translator!
Other than that, I agree with what ejtrans100 was saying. Categorised glossaries would have to be used, as different fields use the same word for different meanings.
Good luck with the project!
A great idea! I’m looking forward to use this glossary and anyway we will have the choice to use the glossary answer or not… The best would be like in Trados a one word auto search when we enlight the word and click somewhere for instance it would display the occurence in all the IcanLocalize translations in the language. A field separator would be important too as has said ejtrans100. It would be a great tool!
🙂
I incline to agree with DrLofthouse. And a little bit with the first two commenters. This will create frictions between translators, for this will be more than a guideline for many of them. It will also look like a translation machine (you just take the word and replace it). This is very dangerous for this tend to make a translation rigid, which should never happen. Different people have different ways to tell things and, from my point of view, this is what makes a difference between translators. It is close to writers.
I expect my glossaries to:
– let me find individual words (like ‘look’) or compound phrases (like ‘look forward´),
– identify clearly the field each word is applied to,
– copy and paste from ‘suggested source’ to ‘target’,
– in-the-spot editing capability to correct mistakes,
– show synonyms (if applicable)
– and direct link to the text it was used in to verify context.
I know it is like asking for heaven but they are ideas. Good luck with glossaries.
This is a great idea. It will really make things a lot easier for us.
Yes,
it’s a good idea. I think we can creat a glossary like that (I translat from English to Italian):
trainer -> (sport) istruttore, allenatore, trainer, mister
There are many possibilities and we have to explain -maybe with an example- when one word is better than an other!
My little contribute
Regards
LIKES:
– translation glossary per client
– client glossary accessible to any translator working on that client’s project
– clients create their glossary
– translators can add entries and their translation
– integrated into all ICL tools (Translation Assistant, text resources, instant translations)
– automatic highlighted terms/phrases that can be found in the glossary
DISLIKES:
– ‘small’ translations that follow and glossary given to whomever is free (so called small translations can take up to 450 source words or so, full of technical terms, if say 5 translators have work on a client’s project, priority for instant translations should be given to them, this will also prevent ICL’s risk/fear of abandoned projects)
– SEO done by translators (as a translator, I may suggest terms, but a) terms should be paid, this cannot be done for free and b) I cannot check what people are looking for, this should be done by the client)
– list of the main phrases made manually by the translator (this would take up more time)
“Tell us how you’d like it to work and what you think it should include.”
Desired features:
1. An option to switch the glossary language, from ALL to single language (as an example, suppose some software has been around in Spanish, German and English for 5 years and, at a given point, the client decides to have it translated into Italian too, I would like to see how some terms have been translated in Spanish or German and have the chance to choose the type of display: any translation, or just Spanish, German etc.)
2. The term should be shown in context (to see how it was used: noun, verb, etc.)
3. A button to highlight a term or phrase that will be added to the glossary automatically (but translation to be added manually, so that it can be more accurate, please have a look at mymemory and see for yourself what automatic alignments do, most of the time they are unreliable).
4. Space for translators’ comments/explanations
My two cents:-)
I’m not sure you can do all that, but you asked for my ideas and opinions, so there you are!
Yup, that’s what we’re going to implement. And like you’re suggesting, we’ll start with very basic functionality and then build it from there.
“have worked on a client’s project”! Sorry 🙂
Great idea. Start with a simple solution and work from there.
As a client I don’t want heaven – I just want what you offered in your newsletter.
My biggest problem is that translators translate the same glossary word across different texts and come up with different translations for the same terms and words.
This gets worse if multiple translators are involved. Especially when creating software and help files and FAQs this is a huge problem: Menu items always have to have the same translation for example, as users can otherwise not understand how the text ralates to their software.
There is no grading involved. There simply is only ONE translation and that’s it.
I don’t know why an early version – or any version – would need a grading system. If I as a client want a translation of a word or term in the glossary fixed, so that it always is translated in the same way, then that’s what I want. That’s why I place it in the glossary. I do this to take away ANY options from the translators to get the translation wrong.
If you can deliver what you are suggesting in the newsletter, you would provide a great solution.
From the comments I can see above it appears you have translators responding who want a grat Glossry for entirely different reasons than suggested by you. Stick with what you suggested, and you will make many of your clients happy who want to get better quality and more consistent translations across multiple documents.
I do NOT want a glossary such as
“trainer -> (sport) istruttore, allenatore, trainer, mister”
That already exists in translation software. There is no need to reinvent this.
I want a glossary that takes away options from translators and forces them to always translate
X with Y.
This is what I understand you are planning – and this would be a great solution.
🙂
Thanks Amir, for your feedback.
@Steffan: I agree with you, nevertheless I would like to comment on your post above, where you say “There simply is only ONE translation and that’s it”. It’s all fine when the translation is good, but when you find out that a translation is not so good or there’s room for improvement, I think that adjustments are in your own interest, especially in the long term. About menus, you’re completely right. A guide or reference is required.