Did I screw up the file filter? Testing the iOS localization package with pseudo-translation
The is Part 3 of the series Localizing an iOS drawing app with memoQ, one cliffhanger at a time.
UPDATE: Turns out Michał Tosza beat me to this one; he has a super concise and clear video about pseudo-translation in game localization right here.
If you read the last two installments, you’ll agree that we’ve made a lot of progress to get Inkpad’s strings translated. We used memoQ’s Regex Text filter to extract exactly the text that needs to be translated, and we threw the regex tagger at the result to eliminate all the nasty inline codes that still remained.
But, but, that nagging feeling… What if I did mess up something with all this regex magic? It would be horrible if I spent hours translating, only to find out at the very end that half the text is missing, or that there was an odd little difference in the output that means the developer cannot reinsert the files into the app.
Also, translations have a nasty habit of being longer than the original. If you’re working from English into, say, German or Hungarian, they tend to be a lot longer. Will the text fit on the screen? Will all the special characters display correctly?
memoQ has a function that allows you to detect such problems up front, as soon as you are done setting up the file format filters to deal with the input. Pseudo-translation populates translations with a quasi-random jumble of characters, optionally also more characters than you had in the source. Just do this, export the files, and double-check with the app’s developer that the result compiles.
Here’s all the things you can achieve with pseudo-translation:
- You can set up the function to insert “strange” characters, where strange can mean accents, or characters from a different script like Devanagari or Chinese. Do these all display correctly in the app? Code page problems have become blissfully rare since we have Unicode, but you may still get fonts that cannot draw characters with accents, or East Asian ideographs.
- Space constraints. You can make pseudo-translated text longer to anticipate longer translations. Will they fit on screen in the app?
- Missing strings. If you didn’t configure your filter correctly, it might skip important content that should be translated. Or, sometimes developers make a mistake, leaving text hard-wired in code, so that it never shows up in the package you receive. When you start the app with pseudo-localized strings, it’s really easy to spot real language among all the garbage. Real language means: Oops! Those are strings that should have been sent to the translator (you), but weren’t.
You can configure pseudo-translation in memoQ in Options / Machine translation, under the memoQ pseudo-translation plugin:
It’s actually a whole lot of fun to experiment with the options you find here. Machine-generated gibberish is even more amusing than the gibberish coming out of politicians’ mouths. Do spend some time clicking around here, and see how the text in Sample text, bottom left, is transformed deterministically into a meaningless letter salad under Pseudo-translated text, bottom right. The consequences are also benign, unlike in national politics, where peace, prosperity and freedom are at stake.
When you’re done playing here, make sure the plugin is enabled and marked as the default one, then head over to Pre-Translate (in the Preparation ribbon tab):
The key here is to pre-translate with no TMs or LiveDocs corpora attached to your project, and to check the Use machine translation option. In memoQ, pseudo-translation is disguised as a machine translation plugin. No offense, all you good people working on building real machine translation systems with meaningful output. It’s just a technical quirk.
Soooo, the pseudo-translated files roundtrip correctly, and the iOS app’s developer told you everything’s fine? Good. Time to translate. Time to deal with a topic where you have no clue about the special vocabulary, and you must go by the usage of a 500-page manual… A PDF manual. Oops. Want to learn how? Check out the next installment.
Part 4: Converting a 500-page PDF user manual with TransPDF
