2017 Internet Freedom Festival Localization Event Report
This year the Localization Lab community made its annual appearance at the Internet Freedom Festival (IFF) with a series of interactive events that included a Qubes OS Spanish-Language Localization Sprint, a localization session, the 3rd annual Localization Summit, and a session of "Speed Dating" Localization Demos. 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
Since its conception, Localization Lab has grown to a community of roughly 6,000 volunteer translators and users supporting over 50 projects supporting Internet Freedom. Through the years, we have had innumerable successes adapting digital security applications and educational materials for populations around the globe and building stronger ties between developer and user communities. In recent years significant strides have additionally been made in the prioritization of internationalization and localization of tools early in design and development, resulting in more usable tools from day one. Even with these successes, Localization Lab has a way to go to make the localization and adoption of the tools we support as effective as possible around the globe. Community events like the Localization Summit help us to better understand the continued and evolving challenges faced by the community so that we can prioritize and address the needs and concerns of contributors.
Relevant Tools, Technologies, and Projects
M-Lab Chrome App
Project Website: https://chrome.google.com/webstore/detail/m-lab-measure/leijmacehibmiomcnpaolboihcdepokh
Project Resources: https://www.transifex.com/otf/mlab-app/dashboard/
Project Website: https://www.mailvelope.com/en/
Project Resources: https://www.transifex.com/otf/mailvelope/dashboard/
Project Website: https://ooni.torproject.org/
Project Resources: https://www.transifex.com/otf/ooniprobe/dashboard/
Project Website: https://www.openkeychain.org/about/
Project Resources: https://www.transifex.com/otf/open-keychain/dashboard/
Project Website: http://pootle.translatehouse.org/
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)
Project Website: https://www.torproject.org/
Project Resources: https://www.transifex.com/otf/torproject/dashboard/
Project Website: https://www.transifex.com/otf/umbrella-app/dashboard/
Project Resources: https://secfirst.org/
Event Overviews & Outcomes
The 3rd annual Localization Summit brought together a group of about 25 individuals to share experiences and brainstorm how to improve the localization experience for all stakeholders in the Localization Lab community. Participants represented the linguistic, geographic and professional diversity of our translator and user community and included several developers of Localization Lab supported tools as well as developers of the translation platform Pootle.
The day began with introductions and quickly moved into an agenda hacking activity in which participants brainstormed localization-related challenges, identified overlapping ideas, and narrowed the pool down to 10 main topics, of which 8 working sessions were chosen for the day:
Localization Workflow: What current challenges faced by developers and translators are limiting the effectiveness and efficiency of localization workflows and how can these challenges be addressed?
Continued Wiki Development: Which Localization Lab stakeholders will a Localization Lab wiki serve and how can we move forward with development of the project?
Community Development: How can we strengthen our existing community and increase the engagement of translators, developers and organizational partners in the localization process and related discussions?
Glossary: What would an ideal multi-lingual Internet Freedom glossary look like? Who would manage it and where would it be housed?
Communication: How can we improve the communication experience within the Localization Lab community so that all stakeholders are connected and well-informed?
Incentives: How can we provide incentives for volunteer contributors to help keep them motivated and show appreciation for their hard work?
Community Outreach: Once tools are localized, how can we market them and educate within the communities that would benefit from them?
Hacking a Localization Sprint Guide: What key components should be included in an open-source guide to support community-lead Localization Sprints?
This session brought together a group of developers and translators to discuss the challenges faced by both groups with regard to localization workflows across Localization Lab projects and identify ways in which these workflows can be made more effective and efficient.
Contributors from the developer and translator sides agreed that there is a large gap in communication between the translating and developer communities. As a result of this lack of communication there is efficiency loss, work is completed that is then not used (primarily on the part of the translators), translation work does not match project priorities, new translators are easily overwhelmed and thus hesitate to contribute, and review of content becomes more difficult. Due to these complications, there are a lot of lost opportunities and the full potential of our translator community remains untapped.
The group also agreed that with a lack of insight into app development cycles, it is difficult for translators to prioritize translation and keep up with application updates. Translators often work on several projects within the Localization Lab Hub and beyond, which means they have a “multi-project” view and requirements and can be spread quite thin. Unlike developers, their focus is not on one application alone whose updates can be followed.
Regarding approach to workflow issues up to this point, participants mentioned that Localization Lab approaches have been more reactionary than preventative. Localization and internationalization are integral parts of an application’s development and design cycles and need need to be smoothly incorporated from step one.
As a result of the session, the group identified several ways in which we could begin to approach the aforementioned issues. Suggested next steps included creating a two-way channel for communication between developers and localization communities, improving localization community engagement with projects, and creating a resource where translators and reviewers can understand how a project is being developed (milestones, release cycles, staging availability). The group also suggested that Localization Lab be aware of projects that are in heavy development and not engage them while they are in transition and that projects not be added to the hub that are undefined or proof-of-concept applications.
The Wiki Development discussion approached the further development of a wiki by first identifying the Localization Lab contributors who would access the resource, and from there, what kind of content would be most beneficial for those parties. The stakeholders and related resources identified included:
General Knowledge: The Localization Lab organizational mandate; organizational goals; a free software overview; Localization Lab communication avenues; Localization Lab Contributor Roles & Guidelines; a Localization Sprint Guide; a glossary hacking guide; and miscellaneous other localization strategy guides.
Developers: How to prepare and add your projects to the Localization Lab Hub; localization best practices; internationalization best practices; Localization Lab Roles & Guidelines for developers.
Translators: Translation platform Getting Started and How-To guides; localization and translation best practices; and Localization Lab Roles & Guidelines for translators.
Language Coordinators: Community management resources; and Localization Lab Roles & Guidelines for language coordinators.
Language Teams: List of available tools by language; digital security educational and training resources by language; and Localization Lab published glossaries and style guides.
Projects: Links to tool overviews and information; project downloads and websites; and project-specific educational and training resources; and project contact information.
The platform that has been largely agreed upon for the Localization Lab wiki is MediaWiki, however questions still remain as to where the wiki will be hosted and who will maintain it. At the content level, it was decided that it would be better to avoid open access and unregulated contributions to the wiki. Similar projects have faced difficulties dealing with spam and having resources too limited to keep up with unregulated edits. The ideal system would see developers and language coordinators as gatekeepers for project specific and language specifica content respectively, with the Localization Lab staff assisting in both areas as well as curating the general knowledge content.
Important next steps in realizing this project are determining a hosting service and maintenance strategy. With those elements solidified, we can begin to transfer content from the Localization Lab website to the wiki and open up contribution to the community.
Community development is important for knowledge sharing, increasing security, understanding functionality of the technology we are working on. By empowering the communities we are giving people the option to threat model for themselves and choose what tools to use.
The ability to read, write and speak English is a unifying factor for the translator contributors of open source apps and on platforms such as Transifex, Weblate, Github and Pootle. Despite this unifying ability and the common interest in Internet Freedom issues and technology, there is a need to break down the community by two factors so that people can have more productive and focussed interaction: projects and language groups.
Coordinating events, physical if possible, is a great way to motivate and reward contributors and build community around projects or language. These events can include regular meetups that piggyback on large international events like the Internet Freedom Festival, they can be regionally focussed or they can be coordinated in conjunction with big name groups such as Mozilla, Google, Facebook, and Wikipedia who may be able to sponsor events and share resources. Regional and language focussed meetups can help grow younger language teams and attract participation. Once the foundation of a language team is in place, the real potential of the participants can be taken advantage of.
Community can also be strengthened through educational activities. Linguistic training and inclusion of professional translators in the community can develop quality, as well as the understanding of technology. Collaborating on guides and resources such as style guides and glossaries is another example of an activity that will strengthen community and quality for translations. Having a wiki where all of these educational recourses are housed, as well as offering a platform for language-based communication and resources will also build community around regional and linguistic groups.
In order to keep collaborators motivated in general, it is important to ensure they feel ownership over projects, have the flexibility to work on a diversity of tools, have the freedom and autonomy to contribute to the tools that are important to them, and have the resources available to understand those projects.
Over the course of the Glossary session participants discussed current state of glossaries at Transifex (TFX in further text), identified several issues, and developed clear and precise goals for future glossaries. They additionally touched on the subject of creation, population and distribution of glossaries.
The current TFX glossary is not unified nor shared between projects. The terminology strategy is nonexistent and isn't standardized. Everyone can edit glossary terms due to the lack of a "lock" option. There is no option to interface with official terminology lists provided by relevant language authorities (i.e. governmental bodies dedicated to language research)
Below are the defined needs for future glossaries:
A glossary needs language-specific standardization of terminology shared across projects. The community needs shared glossaries across projects within a given language for vocabulary-building and uniform localization. This glossary should be user-friendly and easily accessible from the translation platform and outside of it. A logical connection between singular and plural terms as well as gender-specific glossary items would be ideal. The glossary should not be based entirely on English; other languages have more or less requirements that English does and that needs to be kept in mind as the glossary is structured.
Though limited by TFX, having UI interactivity, or the ability to select a glossary term and have the translation platform insert that term would be ideal. The ability to lock reviewed glossary items, as well as the ability to flag a term missing from the glossary for translation would also ensure the quality of the glossary.
It would be useful to research existing tools that already have the terminology identified for specific language (this would fall to language coordinator as a task). The community needs reviewers who are capable of researching the technical terminology in order to confirm or edit the term (meaning, someone who has the patience to track down the exact intended meaning of the word, find the best possible translation and then add it to the glossary.)
Developers can build terminology lists, however localizers are more capable of finding words that need actual research, confirmation, clarification etc. Glossaries can be a project unto themselves, implemented into other projects that are actually going to use the glossary as aid (meaning, the glossary can be project owned by the platform or umbrella organization such as OTF, translators can set time to work specifically on the glossary for their language, without having to work on a project that uses that glossary.)
Communication continues to be a challenge within the Localization Lab community so it’s no surprise that at this year’s summit, participants wanted to return to the subject. With a diversity of contributors comes a diversity of platform preferences, founded in technical, ideological and other priorities.
The discussion began with a comparative look at the different communication platforms used on the Mozilla localization team, which are apparently numerous. In India for example, there are regionally-focussed Telegram groups for each Indian state as well as channels for every Mozilla project. In addition, communication is supplemented with a Discourse channel; regional, project and language mailing lists; a Slack channel; an IRC channel; Twitter; Facebook pages for every Indian state and each language group; a unified Facebook page where all event, project and organizational updates are made; and an Etherpad where translations needs are listed and introductory translation information is provided. All of these methods of communication are documented on the Mozilla localization wiki. The Mozilla experience highlights how communication platform preferences can differ significantly based on groups.
After discussing various communication approaches used by organizations, consensus settled on effective communication consisting of finding a balance between platform diversity while seeking centralization. One way to approach the issue of offering diversity while centralizing information is through the use of APIs which can assist in converging content. Two platforms that were recommended through the discussion were Mattermost and Gitter.
Throughout discussion, one recurring takeaway was that there needs to be more communication from all stakeholders. That includes more regular project updates from developers, which could be in the form of non-technical update logs, and more communication of localization issues from translators, which would ideally be filtered through a language coordinator, prioritized and communicated to developers. Creating project and language-based groups for translators and language coordinators could assist with this communication, as would regularly scheduled meetings for language groups. It was also recommended that translators find developers on their own communication platforms in order to communicate issues and potentially edit and lock strings right at the source.
Localizers and developers should develop a mutually beneficial relationship. There should be an understanding of how promoting the tool helps localization (redirecting people from the website to the tool Transifex page- making sure the user has the app or the website in their language). It’s important to update users on social media when there are changes to the tool
Localization Lab should be more than a translation community; it needs to work better to market and contribute to the promotion of these tools, perhaps by adding animators and community builders to the Localization Lab team. Developers should provide communication materials to be translated, like press releases, and Localization Lab can create a database of journalists and media outlets to help developers in networking.
Localization Lab can offer localization access solutions, in order to narrow the gap between the users and developers. Outreach needs resources and professionals, so how can the community get communication professionals to volunteer? Does the marketing fit the volunteer model of the Localization Lab? Are there any OTF services for communication to collaborate with?
The Incentives discussion tackled the issue of how to keep people motivated and what kind of reward system the community needed.
The group agreed that here should be a better system of acknowledgement of the translator’s effort. Real-life events, giving credit on the programme or the project website, personal gifts (like personalized t-shirts with translator’s name) are great incentives.
Gaming, certificates, symbolic money rewards seem to be counterproductive. Getting personal seems to work really well in our community: narrative-building, messages (as part of regular communication flow in the community), recommendations, and supporting future job prospects of the volunteers. Sending summaries of the work is also important as part of community building, and regular check-ins. Lastly, a little swag never hurts, apparently.
The narrative is extremely important in incentivizing, and the developer should invest more time to present the narrative around the project and why the translator should be involved instead of robotic impersonal messages. More personal relations between developers and localizers can guarantee consistency, ensure steady and uniform work, and make translators feel as insiders to the project.
Hacking a Localization Sprint Guide
A localization sprint, like a code sprint, is a get-together of translators, developers, and trainers involved in a project to jump-start or to go through entire localization of the project. Localization sprints typically last from one day up to a week, and have become popular events in the past three years for FLOSS projects that we support. LocSprints are a way to achieve a significant amount of work what takes 2 months to do, gets done in 2-4 days. There are three types of sprints: community-focused (that focus on needs of one community, usually in one language, and can be multiple projects), project-focused (that focus on a single project and how it meets the needs of various communities, can be done in many languages), and combination sprints (that are a mix of the two).
First, it’s important to create a roadmap together, both what will be done at the sprint, and a plan for what to do in case the work is still not finished. Narrative-building is really important for driving the sprint forward, as is any localization work. What does this do for me? How does this help my community? What unmet needs does it address? These are some basic questions a narrative should address. A good structure to have is 1 reviewer for every 4 translators. It’s really important to have one of the developers available to answer questions on function and context, while a trainer would be valuable to have for bigger questions on digital security needs, learning how to talk about this new tool with others in your community.
Find a safe place to have the l10n sprint. Make it fun, and set a time limit. If it’s not done it time, it’s important to divide the remaining work and set deadlines together, as a group, so everyone does their part. Glossary and style guides (Gender, tone, formality, technical terms, etc.) need to be decided on before the localization sprint even starts to expedite the work. Also having a demo of the tool the group is working on is important to see how it works and later, during the sprint, it’s easy to recognize in context where the strings fit. A tool demo, or a walkthrough, should give lots of opportunities for Q&A.
Some challenges discussed during this session include finding funding for the sprints, and continued App/Tool developer commitment. UX feedback loop needs to be clearly defined as well. Two things to be careful of are working on unfinished products (or projects under heavy development) or on “stale” tools (that haven’t been updated in a long time). This is great exercise to build commitment and accountability for a language group.
"Speed Dating" Demos & Sprint
Due to popular request, Localization Lab brought the “speed-dating” demo and localization sprint format that was so successful with participants last year.
The “speed-dating” demos and sprint sought to bring together a diverse group of translator contributors and Localization Lab Hub project owners to demo and discuss new and familiar Internet Freedom tools. The “speed-dating” format allows for small groups of translators (1 - 3 people) to receive personalized demos catering to their regional, linguistic and technical needs. The 15-minute time limit on each demo also allows participants to connect with a large number of people and tools in a relatively short period of time, allowing them to follow up on any unfinished conversations afterward.
Ideally, after the demos the translator contributors would dive directly into translating the tool of their choice from the projects showcased, assuming a project is available that is of interest and relevance to the individual and the community they represent. Transitioning into focused translation after the demos and with the presence of the project developers offers the rare opportunity to not only collaborate with fellow translators, but also to ask developers questions and provide them feedback in real-time. Due to sustained issues with the network connectivity at Las Naves, we were unable to focus on translation, however instead opened up the demo space for q&a and discussions between participants.
This year’s event involved roughly 20 translator contributors representing 16 different languages: Persian, Arabic, Hindi, Telegu, Serbo-Croatian, Spanish, Portuguese, Simplified Chinese, Traditional Chinese, Finnish, Russian, Norwegian (Bokmål), French, Luganda, Shona, Azeri. Three more projects than at last year’s event were invited to demo and included: GlobaLeaks, M-Lab Chrome App, Peerio, Pootle, Psiphon, Tails, Tor Project, Umbrella App. Representatives from LEAP, OpenKeychain, Qubes and ooniprobe were also available after the demo rounds to chat with translators and answer questions.
Despite the issues with connectivity, the event was a success. Translators were able to meet the owners of projects they have worked on as well as be introduced to new projects that might serve their communities; developers were able to hear feedback from potential users representing more than a dozen countries and languages from across Europe, the Americas and Asia; everyone was able to create stronger ties between translator, user and developer and open channels of communication for future collaboration.
Qubes Localization Sprint
On Sunday, March 5th, Localization Lab and Qubes OS hosted a Spanish-language Localization Sprint in conjunction with the Internet Freedom Festival.
Over the course of the event and the week of IFF, roughly 4,600 words of the Qubes OS highest priority resources were translated into Spanish, including the Qubes Virtual Machine Manager, the Glossary of neologisms and Qubes OS terminology, the operating system Introduction and portions of the Getting Started manual.
The Qubes OS Sprint brought together a project owner from the Qubes OS team and a diverse team of technologists and activists representing Mexico, Chile, Argentina, Venezuela and Spain.
The day started with a Qubes OS demo and then moved into collaborative translation of the Qubes OS glossary and related terminology from the operating system. With the number of new terms and concepts within Qubes, this was a big task to undertake, however by mid-day and after much rich discussion, the full glossary of terms along with clarifying notes in Spanish had been agreed upon - taking into consideration Peninsular and the diverse Latin American dialects - and was ready to upload within Transifex to assist with translations.
After lunch, the rest of the event focused on translation of 4 key components of the operating system: the VM Manager, the Introduction to the os, the User FAQ, and the Glossary. Over the course of the afternoon and the rest of the week at IFF, 4,646 words of those resources were translated by the event participants, resulting in the VM Manager being 98% finished, the Glossary bring 91% finished, and the Introduction and User FAQ being 79% and 10% finished respectively. This work sets a strong foundation for the rest of the translation work to come. Having the glossary and vm managers finalized will guide future translation and significantly ease the challenges that arise with translation of new technologies and terminology.
As a result of the various discussions that took place at the Summit and Sprints, the following were identified as concrete steps to address some of the challenges identified:
- Create a unified glossary.
- Focus effort on regularly published style guides and glossaries.
- Publish the Localization Lab wiki.
- Create language-specific communication channels.
- Continue to pursue communication platform alternatives.
- Publish a Localization Sprint Guide.
- Investigate incentive opportunities for translators.
- Improve documentation of hub projects and development cycles.
Please contact the Localization Lab team if you are interested in continuing discussions that were started at IFF or if you are interested in assisting with any of the above next steps!