Currently, edX has no engineering team or product owner around the internationalization (i18n) and localization (l10n) of the edX platform, edx.org website, and associate products (Drupal, insights, etc). This document is a first pass at the outstanding questions around i18n and l10n we have, primarily from a product perspective, that a full or part time globalization team would need to answer to help us become secure and stable in our translations support. These questions, and their eventual answers, will form the backbone of our globalization strategy.
Nothing about how we do translations of anything (even the platform) is at all easy. Even if we are handed a set of translated strings, if they are for a language we don't support yet, there is significant effort to ramp, execute and maintain a new language. If we are going to move toward deeper language support (e.g. translate the Web site and documentation), and/or more languages (for key markets or partners), and/or content translations (even if we act only as a broker), then we need a business plan for approaching the Global market, we need to shore up what we have (e.g. our Hindi platform translation percentage is below 50% -- that's a language we already "support"), and we'll need more technical and process infrastructure to make significant progress.
Before we move forward with additional support for languages - whether that is releasing new languages on edx.org or building new features that allow further localization - we need to define what "supporting" a language is, what our and our partner's commitments to translation are, and what are target markets are. We need to figure out a long-term strategy plan that will enable sustainable, productive support of a small number of language groups. In addition to the commitment of a full or part time product owner in this area, we will need a dedicated engineering resource as well as input from our marketing and business teams to help us identify target markets and ensure we have a budget that will help us meet our globalization needs.
...
So, before we proceed further, we need to figure out how to apply the contextualization plan (Q2A) to our currently-existing languages.
Q3B: What is our SLA with our customers regarding translation turn around time?
How do we deal with a living codebase
...
?
...
Our platform strings (text areas) change constantly. With a once-per-week release, this means that the chance that there are changed strings live on the platform that do not yet have any translations is very high. For example, the Destination edX team recently did an overhaul of the phrasing on the login and registration pages. Users viewing these pages in Chinese, who would have previously seen the entire login workflow in Chinese, saw the workflow only in English for about four weeks until the volunteer, open source translators on Transifex provided translations for all the new strings.
This is a sub-optimal user experience, and Chinese is one of the fastest-responding teams that we have. Other languages have a slower turn around time - Portuguese took over 2 months to get the new strings fully translated.
We How do we ensure translations are reasonably up to date (and how do we define that)? We need to figure out what is our an SLA for the turn around time for new or changed strings and define how we are going to meet that goal. We will also need to define how we will support contextual review here - we don't want to make teams do a full contextual review for only a few hundred changed strings. So we need to figure out a way to isolate ALL changed strings, locate them in the platform, and release a contextualization review plan to translation teams on a pre-determined regular basis.
...
This will require coordinating the effort of translation teams and engineering teams. We will need to make sure strings are available on Transifex in advance of a feature's release, and that translators can perform a contextualization review before the feature is live on the site. However we cannot involve translation teams too early. This will lead to wasted effort both in translation and contextualization review as the feature changes and progresses 's strings change and progress through development.
We need to define when we would want to provide this type of support, what the timelines would be, who from edX would coordinate with the translation teams (this would require a significant amount of work from a project manager or product owner to coordinate the engineering team's work with the translation teams), etc.
Q3D: What is our content strategy, and how does that inform what languages should we support?
We need to figure out what languages, from a business and marketing perspective, we want to support. We need to critically examine this because releasing new languages are is not free. Releasing and maintaining languages live on edx.org represents a significant cost. We should think critically about dropping support for languages that aren't driving registrations or users to our site. We should focus on bringing in new languages only when they satisfy business objectives.
...