Raise your hand if you’re not interested in saving money on your next localization project. What? No takers? The fact is that everyone wants to get a deal when it comes to localization (and most other services for that matter).
Beyond partnering with a translation company that offers the very best quality-to-price ratio (and we happen to think that Acclaro is unmatched in this category), there are a few tricks of the trade that you can master here and now to shrink your future translation costs. If you get a handle on these insider secrets pre-project, you’ll find that your international goals are realizable and affordable.
1/ Use standard resource formats.
You’ll make your translation agency happy if you adhere to this best practice, but more importantly, you’ll avoid the giant money hole that hard-coding and content embedding can create. Embedded strings or customized resource formats for software often require the development of custom parsers and, in the worst-case scenario, a full-scale internationalization process to extract what needs to be translated. Avoid this costly pitfall by sticking to the standards. No matter your development platform, if you work with Java .properties, .NET, .resx, Ruby-on-Rails, .yml, the open-source .po format and/or other “standard” resource files, you’ll facilitate access to your content and cutback on processing time.
2/ Minimize the use of linguistically dependent strings constructions.
There are three common mishaps that occur with these types of strings: concatenation, lack of contextual comments and multiple variables. Unless you’re a hyperpolyglot, you probably haven’t mastered the grammatical rules of your target languages (yet). So how can you account for the idiosyncrasies, say, of Eastern European and Asian languages, and avoid possible concatenations as you’re optimizing your code for translation?
Use constructions that are adaptable to any language. Here’s an example:
As in the example above, you’ll want to use simple sentence constructions if you plan to target languages with a grammar that is richer than English.
By minimizing possible concatenations and variability in your source strings, the end result will be a smoother translation process, and output that your target users will understand. Remember — your translators grasp the grammatical and syntaxical rules in their language, but they probably don’t know how to implement them using Java code.
3/ Pare down text for translation to user-facing content.
If you’ve worked in software long enough, you know that developers around the world typically learn English in tandem with programming languages and have a good mastery of techie terms. One straightforward way to reduce your content pre-translation is to therefore leave administration (admin) messages and prompts in English, since your admins can likely understand strings like “Error: 312 — Not associated with a trusted SQL Server connection.” Leaving this in English may seem like cutting corners, but think of it as a tradeoff that allows you to allocate precious resources to reaching more international users with the strings they will actually see and read.
You may also want to consider translating only your most essential user support documentation. An overabundance of information is not only costly; it also detracts from the overall user experience.
4/ Select a “pilot language” to produce first.
As a newbie to the international software scene, you stand to learn a great deal in terms of the various kinks your application will encounter throughout the localization process and in-market rollout. A small-scale debut into one or two languages will afford you the chance to work out the bugs before you go fully global, allowing you to set the stage for a smoother localization process for languages to come.
Stay tuned for more cost-savings tips this summer.
Photo attribution: Vectorportal