My conclusion is that the way I gathered the cell entries must have resulted in damaged data. I copied from .docx documents that were opened by acrobat pro, and previously handled by translators around the world.
That's certainly possible. A better translation workflow would involve minimal manual handling such as you describe. I typically use tools that can work directly on IDML files (which is a markup-language equivalent of an InDesign file, more or less), and when it's my job to select translators, I typically only choose providers who can work with those tools. That isolates the workflow from many sources of potentially damaged data.
Even though it may look expensive, I usually suggest to people unfamilar with the localization process to hand their English files over to a language service provider. Paying someone else to fix these problems is typically a significant cost savings, unless you rate your own time as being worth zero dollars per hour. And, for what it's worth, if you already have your translations in some kind of tabluar format, it may well be easy for someone to groom that data and turn it into a translation memory database, which could then be applied directly to your IDML. That's the kind of thing I do all the time, to be honest. It might be a great deal cheaper than you'd expect.
However, if you're going to try to fix this without handing it off to the language professionals, I still think that some sort of tooling would help you out. For example, a tool that could tell you which string a merge failed on would be to your advantage, right? You wouldn't be speculating as to the reason why your merge failed, if you knew which strings were problems. I suspect that Robert's game-specific tools could be very useful to you, here. If you'd like a second opinion, and are willing to share your massive CSV, I'd be happy to take a look at it to confirm or deny your conclusions regarding potential damage to your data source.
9
Replies
AdChoices