By Erin McConnell
In an ideal world, a few dedicated multilingual volunteers would be all that is required to make open source technology available for communities in need. Individuals would translate and review the resource and then it would immediately be released. In reality, however, publishing new translations requires more than multilingual manpower. Translating technology resources is a complex process that involves a number of steps to ensure a tool can be localized as well as active communication with developers before, during, and after the translation has taken place.
There are many considerations that need to be taken into account before a tool can be published in a new language. The user needs to be able to access the translations in the app, either through an in-app language selector or through operating system support, languages like Arabic need right-to-left support, and developers need to have the resources and manpower to continually update multiple languages.
Maintaining open channels of communication with developers helps ensure that tools are ready for localization. This preparation is important for all of our work at Localization Lab, but even more so during Localization Sprints.
Prior to the Sprint
When preparing for a recent Localization Sprint, initial communication with the developers and content creators of the tools was key in determining which applications could be localized and how and when they would be published.
Sprint participants at FIFAfrica in September 2018.
The ultimate goal of the sprint was to finish updates to Signal iOS and Android, and fully localize Signal Desktop in Bahasa Indonesia, Khmer and Burmese. Through communication with the Signal team we solidified the following information:
Signal Android and iOS could support all three languages.
The languages would be included in the in-app language settings (This means that the language can be selected in the app even when the rest of the device doesn’t support the language.)
Signal Desktop is limited by Electron framework so Burmese could not be supported.
Signal Desktop does not have in-app language which meant that any users would need to use their entire desktop device in Khmer or Bahasa Indonesia in order to use the application.
Signal Desktop, Signal Android, and iOS updated translations with new releases approximately every three weeks.
Our conversations with developers allowed us to better understand which applications could be localized, where to focus our translation efforts, and approximately when finished translations would be incorporated into the applications.
Participants at the Southeast Asia Sprint
During the Sprint
Localization provides users with an intimate look at a tool, its features and functionality, design and the source language used. Sprints are, thus, an excellent opportunity to gather user feedback from communities that might not otherwise have the opportunity to provide thoughts and suggestions to developers. At sprints we collect feedback throughout the localization process, but we also facilitate discussions and walkthroughs for groups and individuals in order to gather information about the user experience. This feedback is then aggregated and shared with developers after the sprint, and we follow up on any progress to implement feature requests and resolve bugs.
We focused discussions at this sprint on “Life after Localization” and the community outreach and marketing of localized Signal and other digital security tools. This left participants with a lot of useful information on the resources that are available to engage communities, what challenges they faced when trying to increase adoption of tools, and strategies for increasing uptake.
After the Sprint
Following Localization Sprints, there are two main areas where Localization Lab follows up with developers: Coordinating the release of finalized translations and communicating user feedback from events.
There have been situations in the past when content was not published as expected or a new language was not added to the in-app language list, and in those cases we followed up closely with developers to identify why content had not been published and to ensure it was made available as soon as possible. The feedback we are able to gather from the events are invaluable for developers who want to make their tools accessible and user-friendly for diverse language communities. Sprints allow participants to have an intimate view of the tool and its use, putting them in a unique position to say whether or not a tool’s interface and terminology choices are culturally relevant for their communities.
Key Takeways
Communication with developers is key before, during and after a Sprint takes place.
It is always preferable to have developers available at events to bridge the gap between the people creating technology and the people who are using it.
End-user opinions matter! Diverse end-user feedback is essential when it comes to ensuring that a tool is adopted in a new community. When developers prioritize diverse end-users in the design of their products, communities are more likely to feel ownership of those tools.
