2016 Localization Summit and Sprint Report
On March 2nd and 3rd, 2016, Localization Lab held a series of events at Internet Freedom Festival (IFF) including a festival session, a Localization Summit, and a Localization Sprint. These events focused on three primary goals: improving localization processes, relationship building between developers and translators, and finishing up as much translations as a group, taking advantage of working with developers and trainers directly.
State of the Field
The Localization Lab offers a unique opportunity to connect project developers to the end users that translate their tools. In-person gatherings for community members is essential for a strong, cohesive community of volunteers. This is an important step in establishing sustainable localization practices within the greater community of people fighting for Internet freedom.
Relevant Tools, Technologies, and Projects
Net Aid Kit
Project Website: https://netaidkit.net/
Project Resources: https://www.transifex.com/otf/netaidkit/dashboard/
Language Priorities: Ukrainian, Turkish, Spanish, Chinese, Arabic, Farsi, Russian
Project Website: https://f-droid.org/repository/browse/?fdid=org.schabi.newpipe
Project Resources: https://hosted.weblate.org/projects/newpipe/strings/
Language Priorities: Spanish, Chinese, Tibetan, Farsi, Russian
Project Website: https://dev.guardianproject.info/projects/panic/wiki
Android Downloads: Google Play Store Download, F-Droid Download
Project Resources: https://www.transifex.com/otf/rippleapp/
Language Priorities: Spanish, Chinese, Tibetan, Farsi, Russian
Project Website: https://tails.boum.org/
Project Resources: https://tails.boum.org/contribute/how/translate/
(SHA1 fingerprint: 11:4C:21:CB:2B:5F:C5:05:83:81:D4:A3:E8:B4:BD:CD:14:45:7D:FB)
Language Priorities: first pages to be translated for a language to be added to our website are https://tails.boum.org/contribute/l10n_tricks/core_po_files.txt
On March 2nd, 2016, the Localization Lab hosted its second ever Localization Summit - a gathering of translators and developers that are part of the Localization Lab community. In-person gatherings for community members is essential for a strong, cohesive community of volunteers. This is an important step in establishing sustainable localization practices within the greater community of people fighting for Internet freedom.
Following the Localization Summit, a Localization Sprint was held on March 3rd, 2016 with many of the same Summit attendees as well as several additional developers and translation contributors. The goal of the Sprint was to convene a group of translators from the Localization Lab community with developers from several OTF supported projects to translate Internet Freedom Tools (IFTs) into more than 10 different languages simultaneously and to identify localization and user challenges while providing real time feedback to developers of these important tools.
Localization Lab managed the logistics and support for fifteen translators to attend these events.
The Localization Summit was attended by approximately 30 people and was a day-long event with two blocks of working sessions, one in the morning and one after lunch on the following issues:
Project Lifecycle and Localization: How can localization be better integrated into the research, design and development of projects?
Life After Localization: Once tools are localized how can they be better marketed to and adopted within the communities they are made available to serve?
How to Provide Feedback to Developers: How can translators and contributors provide effective feedback about tools and translation resources to developers?
Need Bank: What would a Localization Lab platform - or "need bank" - connecting end users, organizations, translators and developers based on localization and technology needs and skills look like?
Training and Helpdesk Support: What training, resources and references are available for translators and end users of the tools localized within the Localization Lab Hub? What kinds of training opportunities can the community support to ensure a solid understanding of these projects?
Managing Language Teams: How can language teams be better organized and managed to increase contributor participation and investment in the community?
Localization Platform Alternatives: As a result of the morning session’s discussions, the need to explore Transifex alternatives was identified by both translators and developers. What are the community's needs and preferences in a translation platform and what alternatives exist that might address those needs?
Quality Control: Where are the challenges to translation quality and how can they be addressed within the Localization Lab community through guidelines and workflow management?
The Localization Sprint was focused on allowing the language groups to learn about each of the projects that came to the event through a “speed dating” round. It was followed by the sprint; a rapid translation and feedback of the tools they just worked on to developers. What normally takes a couple months we get done in one day when we have the opportunity to ask questions and interact with the project owners and trainers. Roughly 30 people were in attendance.
Before the summit, attendees openly brainstormed ideas for discussion in pre-summit community meetings. These were narrowed down to 8 specific working groups for the day:
Project Lifecycle and Localization
The project lifecycle and localization discussion centered around brainstorming how to incorporate localization into the research, design and development of a project. The biggest takeaway from the discussion was that each project is unique - there is no one way to incorporate localization considerations into the design and development of a project. For that reason, active, constructive and consistent communication is key for the success of localized tools.
A large inhibitor to communication in the community is the lack of one communication platform used by all contributors. Having one platform to connect them all would allow for several best practices identified by the group to be possible: regular project updates from developers, including announcements of any releases and project updates before they happen as well as announcements of translation releases; notifications of finished translations and finished review from translators; calls for projects needs including translation and testing. There is additionally no way to effectively communicate bugs and issues outside of the Comment / Issue feature in Transifex which among other shortfalls doesn’t allow the user to distinguish between linguistic and technical bugs or issues found post-translation and during the translation process and is not ideal for issue tracking and follow-up.
The group also noted that having nightly or regular builds incorporating translations - whether reviewed or not - in order to do localization testing would be very helpful. This would allow reviewers in particular to more effectively review strings and identify issues before official releases.
To follow-up for this conversation, continued research into a communication platform connecting all actors in the OTH Hub is key. An effective way to connect all the actors in the Hub would pave the way for many of the suggestions that emerged from discussion. Additional research is needed into platforms to support the developer - translator feedback and bug reporting loop as well as into tools for effectively localizing documentation and large blocks of text.
Life After Localization
The “Life After Localization” discussion approached the issue of how to promote the use of tools after localization but ultimately a lot of the conversation revolved around how to more effectively localize the content of tools and documentation so that they would be more relevant for the communities trying to use them.
A recurring theme of the day’s discussions, the need for a unified glossary to assist translators with terms and technical frameworks as well as to streamline language, was identified in the group as a necessary aspect of making tools and documentation accessible. You cannot promote these technologies without a unified and accessible vocabulary. The group also reiterated the need for simple clear language in tools and documentation in order to facilitate translation and limit confusion and discussed using translators of tools in social media campaigns and promotion of tools. Localization Lab translators are often users of these technologies and are a great resource for reaching out to regional communities who might benefit from using a localized tool.
An interesting idea to emerge from this discussion is the idea of using translators in codesigning or transcreating tool documentation instead of simply translating it. Utilizing translators’ insight into their communities, documentation could be tailored linguistically and in design to speak directly to a particular audience. This co-design of documentation could effectively happen in the context of a Localization Sprint or another collaborative training event involving translators, end users, developers and trainers.
As a result of this discussion, the need for research into creation of a relational glossary for all Localization Lab projects as well as into the idea of translator and user-created documentation have been identified. Looking into ways to engage translators in the social media promotion of tools once translated and creation of “language profiles” containing more nuanced cultural information about populations, their needs and expectations in technology and security would also help build on this discussion.
How to Provide Feedback to Developers
In the “closing the loop between developers and localizers” session, the group went over ways to improve that communication loop, and then identified a handful of common problems. Gus Andrews of Simply Secure started off by briefly giving the presentations on bug reporting and graphic prototyping she was giving later in the conference. Localizers were enthusiastic about this, and seemed to get a lot out of it, which may improve communication. “I feel like I understand better now how developers think!” one said.
Localizers wished they had a better sense of the timeline of projects. They often don’t hear from developers about when a version of a tool will be finalized, so they don’t learn about deadlines in a timely way. Often, localizers were concerned about slow replies they got from developers. One potential solution raised for this was having meetings at a specific time — possibly having localizers get in on the regular IRC meetings or calls developers hold. They wanted a development flow that included L10n. (It is worth noting this is something UX specialists need as well.)
Timing and mechanisms of feedback were thus also problematic. Localizers noted there are no forms for feedback during, rather than after, translation. They wished teams had a community manager who could help them get through to developers. It is probably worth ensuring translators have access to community managers on more-established teams, like Tor and Signal.
Localizers wanted to see tool-building teams doing testing of translation, just as they would with UX or QA.
Being able to see where a string of text appears in a program is critical, localizers agreed, but there are currently no tools for doing this. This means they sometimes cannot judge what a string means and give the correct translation. Some localizers thought that nightly builds might be of use in helping translators see context for strings.
There were specific kinds of feedback localizers wanted to be able to provide to developers: Priority of a given translation change (Attendees felt the presentation on bug reporting helped give them better tools for doing this!); systemic issues about character sets; and categories of constant concern to localizers.
Looping back to the “Project Lifecycle and Localization” discussion, a big takeaway from this discussion was the need for better communication mechanisms as well as a better way to provide feedback and track it and better localization testing and availability of context - potentially through the availability of regular builds incorporating translations. One quick thing that could be done to specifically address the biggest problem areas for localizers (common bugs) is a quick write-up - blog post or wiki resource - overviewing these common issues and identifying ways to approach them.
The “Need Bank” discussion tackled the idea of creating a “Need Bank” that would connect different players in the OTF Hub based on services needed and skills available. A parallel idea would pair developers and end users from the beginning stages of project design and development through localization, testing and training to help create sustainable projects and localization and create a sense of accountability - of developers to the end users and of the end users / translators / testers to the tool and developers. The idea being that people will be more committed to using, promoting and updating tools that they actively participate in creating.
The potential players in this need bank would be: Translators, Users, Localization Coordinators, Developers, Project Managers. The potential needs addressed would be: Training & Tool Pairing, User Feedback & Testing, Translation & Localization Testing, and Culturally-Specific Design & Need Recommendations.
As a result of discussion, several challenges or questions were identified that would need to be addressed to move forward with this idea, including: Determining the scope of this project (Will it be like a skills offered / services needed board? Or will it be a co-design project?); and Where would this need bank be housed? (Forum? Up until now, needs have been articulated in the Google Group.) Further discussion and interaction with the community is needed to move forward developing this idea and identify whether it is a need or not.
Training and Helpdesk Support
The training and helpdesk support discussion revolved around how as a community we can create training and educational opportunities for translators as well as increase engagement amongst community members . As a result the group identified several different activities and resources that could promote digital security and internet freedom tool understanding and awareness.
Amongst translators, proposed activities included: the continued organization of Sprints and Summits, the idea of physical “Glossary Jams” where translators and potentially developers help build glossaries, supporting regional face-to-face meetups of translators in closer proximity, supporting “mentor” relationships between seasoned and new translators in the Hub and promoting virtual language-specific and/or project-based virtual meetings.
Proposed engagements between trainers and translators included virtual AMA sessions based on general or identified areas of confusion within digital security and tool usage.
Continued AMAs with developers and project managers were also brought up as a great way to engage with developers and answer any questions surrounding tool use. Usability and/or user/localization testing events - either virtually coordinated or in person - could help also translators understand tools better while also helping developers with design and testing. A better user feedback system would also help support translators and address their needs.
In addition to virtual and face-to-face engagements and communication, the need for a repository where existing resources and references could be housed was articulated. These resources could include links to project websites and training materials, style guides, digital security educational information and links to existing training entities and links to localization best practices resources.
Engaging more with Transifex staff was also brought up through the idea of webinars or AMAs with Transifex staff.
Other ideas proposed included offering “office hours” (trainers, developers and localization lab staff) and potentially hosting chats in which translators have an hour of training in their native language. This idea overlaps with needs addressed in the discussion about developer and translator feedback in which localizers articulated an interest in having opportunities to engage with developers at designated times to ask questions.
Managing Language Teams
Several challenges in keeping active and engaged teams were identified in the “Managing Language Teams” breakout discussion including: the Roles & Guidelines created in 2015 have not been implemented, there is no standardized screening process for translators, there is no functional way to mass-message language groups or project translators, there are large numbers of inactive or minimally active translators on some teams with a lack of dedicated reviewers and coordinators, translator work can be over-written by developer updates and affect reporting on a translator’s contributions, the glossary is not well managed or structured across languages and there is a need for a central repository for guidelines and reference for the hub.
As a result of discussion, several ideas for improving team effectiveness and cohesion were proposed: Creation of a Localization Lab Wiki (which Localization Lab has already begun research into in conjunction with community members), creation of a relational glossary and guidelines for who should maintain it, creation of a screening process and guidelines for communicating with translators if they are inactive before deleting them, revision and implementation of the 2015 Roles & Guidelines, creation of a peer/promotion system for translators to move in rank to reviewer or coordinator, better use of the TX announcements function to let translators know when tool updates are available or translations have been finalized and included in a release, investigation of communication methods for mass-messaging language groups, promotion of communication from developers / language coordinators with translators to increase engagement and creation of an incentives program to reward and motivate translators.
Localization Platform Alternatives
As a result of the morning session’s discussions, the need to explore Transifex alternatives was identified by both translators and developers. During this discussion, the group put together a preliminary matrix for comparing Transifex alternatives and identified some next steps for building on the matrix with translator and developer feedback.
In order to move forward looking at Transifex alternatives, the group proposed surveying key developers, project managers and translators within the Localization Lab community and requesting their needs in a web-based localization tool. The information can then be compiled and added to the draft matrix so so that potential tools can be scored and ultimately tested.
There were several areas of overlap in the discussions surrounding quality control and managing language teams. Noted in both discussions was the need for a better communication platform that will allow translators to not only communicate amongst themselves (and mass-message) but also allow more efficient communication between developers and translators. A better communication platform would help to tackle some of the challenges to quality identified by the group including: an efficient developer - translator feedback loop, announcements of resource and translation updates, and increased engagement between language coordinators, reviewers and translators to ensure translation quality.
As identified in the Managing Language Teams group, quality of translations would benefit from the implementation of a standardized glossary and additionally from screening contributors. Consensus was made that ultimately only translations having been marked as “reviewed” should make their way to applications and that pulling those translations on a regular basis into test builds for localization testing would be ideal.
As prerequisites to providing quality translations, the discussion also identified the need for thoughtful technical writing in the source language, ensuring the localizability of source content (particularly in problem areas like plurals, gender, placeholders, bi-directionality, neologisms, character sets etc.), review of new source strings by translators prior to finalization and translation and the availability of more context (screenshots and developer notes).
Transifex-specific barriers to quality translations include the glossary and the voting/suggestions functions being ill-placed and implemented in the UI in addition to the lack of effective communication tools.
The results of the Localization Sprint were as follows:
We translated 12,398 words and 2,117 words were corrected by the reviewers at the Localization Sprint into the following languages: Arabic, Farsi, Spanish, French, Shona, Luganda, Russian, Georgian, Ukrainian, Norwegian Bokmål, Finnish, Serbo-Croatian and Portuguese. To give some context, 12,000 words is the equivalent of 15 typed pages and/or between 25 and 40 web pages. What normally takes a few months to complete we accomplished this together in one afternoon. This is made possible through having a chance to collaborate directly with project owners or developers, and have assistance from trainers in a localization sprint.
We had a speed-dating round where the projects all had their own stations around the room, and the language groups got to spend 5-7 minutes learning about each project and how it can help their community. We convened teams of developers from the projects to work side-by-side with translators throughout the day to answer their questions and to understand and hear user feedback in real time.
Developers told us how valuable it was to have the opportunity to sit face-to-face with users and supporters of their tools to better understand the needs for and hangups related to their tools.
“The sprint not only enabled me to localise my app, it also helped me to make valuable connections with activists in other countries. A true community event!”
Charlie, Co-founder, greatfire.org
For most translators, this was the first time they had ever sat down to discuss the tools they were translating with the developers of that tool. One translator described the event as “Fun, engaging, fast paced [with] so much to learn. Upskilling in just one day!”
Since the Localization Sprint, we have seen a continued dialogue between translators and developers about their tools as well as continued enthusiasm from translators who are following through with translation of projects they began at the Sprint. We see this work as the building blocks of a positive change in how we create the technology-- working the end user and anticipating localization from the first step. It is our goal that community members will eventually be able to host their own events.
We will be following up on the Summit sessions by doing further research and setting up plans of attack (involving Localization Lab staff and the creation of community task forces) to address several overlapping needs identified in discussions including:
- Creation of a Localization Lab wiki.
- Identifying and testing Transifex alternatives.
- Finding an adequate communication platform for all Localization Lab contributors.
- Creation of a standard translator screening process and dedication to identifying language coordinators and reviewers for language groups and projects.
- Updating and implementation of the Roles & Guidelines for Localization Lab contributors.
- Research into creation of a cross-project relational glossary.
The Localization Sprint participants committed to finishing their translations - of which a number were finished by the end of the day. For the developers, that means taking the translator feedback into account, establishing regular communication with the language coordinators, and giving credit to the translators that were involved.
Recommendations for OTF and IFF Organizers
Community gatherings are essential to the growth and health of the Internet Freedom community. Unfortunately translators and those working towards localization of Internet freedom technology have often not been a part of these gatherings until now. The response from the translators and developers alike at IFF demonstrates the high value associated with incorporating these members more deeply into in-person gatherings that are a cornerstone of this community.
Most time consuming was the issue of visas. We put a lot effort in having a diverse group, but that meant most people were coming in from Asia, Africa, or the Americas and almost all needed visas. If there were a logistics service for our community to assist with visas and travel arrangements, and if the schedule for IFF were available earlier, a significant amount of the scheduling burden would be lifted. By spending less resources on scheduling and booking developers, trainers, language coordinators, and partner organizations, we would be able to focus more on programming to make this as successful of an event as possible.