How should we deal with clients who don't understand localization? Thread poster: CELC Inc
|
|---|
CELC Inc
Local time: 13:40
Japanese to English
+ ...
I recently dealt with a software localization client who posed the following problems:
1) Rather than the application .exe and its documentation, I was given all of the GUI info in XLS, and not allowed to check my own work save as text.
2) Demanded the GUI and dialogues first (rush) and the Help last.
I wonder what others do in these situations? I'm not established enough to tell a new client, "Translation must start with Help to be effective," or "You're ... See more I recently dealt with a software localization client who posed the following problems:
1) Rather than the application .exe and its documentation, I was given all of the GUI info in XLS, and not allowed to check my own work save as text.
2) Demanded the GUI and dialogues first (rush) and the Help last.
I wonder what others do in these situations? I'm not established enough to tell a new client, "Translation must start with Help to be effective," or "You're making this a lot harder than it has to be for both of us by not providing the application file..."
What should I have done here?
Appreciate any opinions I can learn from and grow on... ▲ Collapse
| | | | | experience from both sides of the fence | Jan 30, 2004 |
I've had experience from both sides of the fence, and can appreciate why some things are done in a certain way...
Usually, the localised product has to reach the market as soon as possible after the original product, and no-one will want to hold a product off the market just to wait for other languages to be ready too!
So to reduce the time gap, localisation starts as early as possible, when the sw is stil in beta stage and when the documentation/help is not ready yet (... See more I've had experience from both sides of the fence, and can appreciate why some things are done in a certain way...
Usually, the localised product has to reach the market as soon as possible after the original product, and no-one will want to hold a product off the market just to wait for other languages to be ready too!
So to reduce the time gap, localisation starts as early as possible, when the sw is stil in beta stage and when the documentation/help is not ready yet (because the sw team and the doc team work in parallel).
The XLS format is useful for the engineers to allow them to fold translated strings back into the code - I've worked with km's of xls strings for several yrs now. It's definitely hard to start with, but you get used to it (16 yrs ago I used to work in the actual code, and that was much worse!). What helps a lot is if the XLS file also has a column with the string ID, and not just Original - Translated columns. The string ID can give a good clue as to where the string will appear in the sw.
I've also worked with strings provided as a simple 2-column word table, and that was a nightmare! luckily at least they were not sorted alphabeticaly (as they sometimes are) but by context, so all related strings were together and it was easier to "guess" the final context.
However, the translators should _always_ be given a running beta of the sw (to check things in context) as well as any previously localised material (running build + xls files + doc of previous version).
[It is also true that the more reference material the slower the translation process is, as you need to check pretty much everything - and some translators will not use it even if they have it, to speed things up ]
Usually, after having gone through the translators, the XLS strings go through a reviewer, who should have experience with the product in question and also have access to a running build of it.
Then it goes through engineering and usually at this stage the doc translation starts.
During the doc translation, a translator or reviewer may notice that some strings had been wrongly translated due to lack of context - at this time it may be still ok to notify the project manager, who will liaise with the engineers and fix the wrong strings. This does not always happen, unfortunately, but there is no reason why it shouldn't be possible. When it is possible, it is because the localisation team does indeed work as a team and not as isolated units. The translator is only a link in the long production chain and it is important that communication along the whole chain works as it should, with no valuable information lost along the way.
Throughout the sw and doc translation there should be a query system set up, a structured way for a translator to ask any query that might arise, which should be answered either by the agency staff or the end-client.
Then, when the doc is in DTP, the sw is in testing and there should always be a language specialist involved in the sw testing (to catch truncated strings, wrong translations due to context, problems with shortcuts...) - this part is usually done in-house by the agency, but sometimes freelancers may be called to work in-house for the testing phase, it depends on the agency and their internal resources.
The same by the way goes for the doc: after DTP the files should be checked to ensure the screenshots are ok, all text is formatted as it should, etc.
If shortcuts are taken during this long process, it will be visible in the end-result. The key is good team work, and realising what the various stages are, who are the various people involved and setting up a good communication line to ensure that no information is lost.
This is not such a rare situation, it does exist and when you can work in such an environment the quality of your own work gets better, as you feel more directly involved in the final product and aware of the importance of your contribution to the whole chain. ▲ Collapse
| | | | Doru Voin 
Romania
Local time: 07:40
English to Romanian
+ ...
| Documentation | Jan 30, 2004 |
[quote]hopson wrote:
1) Rather than the application .exe and its documentation, I was given all of the GUI info in XLS.
I've been involved recently in a SW localization + User Manual translation project for a Japan manufacturer. As usually (unfortunately), the client insisted on having the strings translated first. This is the normal practice (i.e. clients always asked this, "the interface is very important", "have to check stig lenths first" and so on). However, I was lucky enough to have access to the documentation in the first place. This helped me A LOT, as you can imagine.
In my opinion, doing blinded a SW localization project (w/o at least relevant documentation) is a sure way to disaster. I for one would avoid this type of clients.
Now, if you have accepted already/have to accept for commercial reasons the project and everything else fails (explaining the client you need the documentation at least, etc.), I would recomment looking for documentation for previous versions of the same product. Usually this is considered public info.
Regards from Bucharest,
Doru Voin
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » How should we deal with clients who don't understand localization? | 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 » |
| | Protemos translation business management system | Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!
The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
