Translation Management

From DevSummit
Revision as of 23:33, 9 December 2015 by Jucsanch (talk | contribs) (Created page with "=Translation / Localization session (led by Mark Burdett)= Mark began the session by explaining the how EFF's U.S.-based organization history led to most documents being avai...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Translation / Localization session (led by Mark Burdett)

Mark began the session by explaining the how EFF's U.S.-based organization history led to most documents being available only in English. As the political climate around impact litigation has evolved, EFF resources became popular all over the world, and as a result, the demand for localization grew.

It's worth noting that in the tech sector, even a non-U.S.-based organization can be tempted to default to English. It's more work to localize, but offers far greater opportunity for engagement, and therefore impact.

One massive challenging with localization projects is maintenance. Once the original copy (in English or another language) changes, how are updates to the other languages handled? Are they retranslated from a single language that's considered the primary copy, or do they evolve in their own directories? Worse, do the translations stagnate, and the various localizations drift apart in their meanings?

Consider adding line items to grant proposals to offset the cost of localization. Effective engagement often results in greater impact, which can mean more funding down the line. If your organization is not large enough to consider external funding, focus on mobilizing grassroots supporters.

Volunteer translators are typically more passionate than professional ones. Depending on the tone of your documents, you may prefer one or the other.

In terms of technology used for managing translation, use what's right for you and your community. Any attempt to force a tool on an unwilling volunteer is not going to work well. Some folks recommend using GitHub, mostly for transparency and auditing, but some translators expect to work by emailing word processing documents back and forth.

For the tech-savvy, there's an attractive file format called XLIFF (XML Localisation Interchange File Format). Oddly enough, even professional translators don't always use it, but standardizing on it makes the use of automated frameworks much simpler. For Drupal users, there's a translation module that understands XLIFF, and preserves markup.

Make sure you understand the implications of localization on the context of your document. If translating for the web, different character sets and fonts can drastically affect layout. Line spacing, font face, even encoding can affect how your document is perceived by the target community. Pay attention.

Two professional translation services to recommend: Transifex (free for open source software projects!) and Memsource (professional contractors, pay by the word).

As important as it is to understand localization and do it right, use your judgment. Localization efforts often consume resources more quickly than young organizations realize. Prioritize your mission, and use your judgment as to how to spread the message. If you jump into localization efforts too early, you may get mired in technical implementations and end up obligated to maintain documents that are no longer mission-critical.