| 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 (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.
| || || |