3 min read
‧ 3 min read
The Metabase project has a lot of users for whom English is not a first language. There are also a lot more potential users who would be able to use Metabase if it provided an interface in their native language.
However, the team has neither the in-house language proficiency, nor the funds to hire translators in all of these languages. Additionally, we have a fairly high bar for design and copy, and are in active development, which means that there is a fair bit of work to be done in translation.
To explore the project’s ability to deliver a localized experience, we’re going to take a crack at it over the next few months. This will occur in two main stages per language.
The coverage should be complete. While occasional regressions from this standard are okay in the event of a launch, the expectation is that once a language enters the primary list, there will be a consistent level of quality and coverage of translations that hovers around 100% complete.
The lengths of the translated text can’t break the design of the application. If a translation breaks our design, one of the two need to be fixed.
The translations should have a similar feel and tone as the english versions — helpful, informal and nice.
There should be an individual or institution that commits to following the ~6 week release cadence of the project, and making sure that their language is up-to-date on any language tweaks. At the start of a release process, we will send out an email describing the features we plan on working on and the expected changes in UI. Once those have been stabilized, we’ll then send out an email approximately 1 or 2 weeks away from the release. At that point, it is expected that the individual or institution will commit to providing translations in time.
Once a language is already translated, this will be a fairly modest time commitment, but an extremely important one to follow through with.
We will additionally maintain a list of secondary languages. Depending on the scale of localization, we might or might not provide a way for end users to select them. They will not be publicized or made easily switchable into.
If after a release or two the quality of a language drops, the core team might drop that language from the primary list to the secondary list. On upgrade, we will warn the administrator in the Admin UI that they are using a currently “less supported” language.
This is not an effort the core team can do on our own. We need individuals or institutions to step up and help us. The help will not be quick and glamorous, but hopefully the payoff of helping others who speak your language to use Metabase will make it worthwhile and gratifying for you.
If you’re interested in helping, please sign up here.