Language tools/Language Team Plan

Language Teams: Building for Success

Introduction
Language teams are groups of people with a common interest (compare with SIG) to help improve, provide feedback and help educate our language communities of readers and editors about Wikimedia software enhancements and tools built by the internationalization team.

Terminology
Language Team is a simplification of the term Language Support Team used earlier. Members of a language team will be referred to as language representatives.

Why do we need language teams
We need to work with our community (readers, editors, admins) for various language wiki projects to educate them about new language support features that are being developed as well as get feedback from them about their user experience and any improvements needed. Past attempts at establishing such support teams have been partial successes. Once folks sign up to participate, having a working relationship and sustaining interaction and activities driven by our goals is crucial to maintain these teams.

Skills needed
In order to be effective, language representatives need the following skillset -


 * Fluent English speaking and comprehension skills
 * Participation in a Wikimedia project in their language of interest: active Wikimedians in language wiki projects other than English or other multilingual Wikimedia activity (MediaWiki, crosswiki issues)
 * Deep understanding / subject matter expertise of the languages you are interested in (e.g. education, linguistics background, translator, professional i18n software development, User of i18n software )
 * Specializations such as typography, fontography, calligraphy are great additional interests to have

Language communities and development priorities
We currently support 285+ languages in the Wikimedia universe. That’s a lot. The i18n engineering team has limited resources and a time bound mandate to add language support to support hundreds of languages through development of tools and technologies. It is prudent for us to consider a top 10 list of language groups to engage and cultivate initially. Language communities that have active and healthy participation from their users (admins, editors and readers) are the low-hanging fruit in developing effective language teams. However, there are other factors such as geography, level of interest and positive engagement that influence choosing a top 10 list of language groups to work with. The i18n team plans to bootstrap 10-12 languages initially. The team is in the process of identifying these initial set of languages.

Communications
Mailing Lists and Wikimedia hangouts:
 * Using Mediawiki-i18n: Mediawiki-i18n has some traffic. In practice, it's not well-defined. Maybe we can just continue using it. But maybe the current people there will feel that we are elevating some languages and feel that they are discriminated. Maybe Mediawiki-i18n should be defined as a more technical list, and a new list can be useful for language representatives.
 * NL: I think we can very well repurpose mediawiki-i18n which barely has any traffic now.
 * Using Wikitech-l
 * Using Wikitech-ambassadors
 * Using Translators-l

Could be reused for language representatives:
 * Village pumps, technical sections of Village pumps if those exists
 * Signpost

Social networks:
 * Using Twitter, Facebook, identi.ca, Quora, Stackoverflow, Planet Wikimedia - any related online networks.

Blogging:
 * blog.wikimedia.org/technology
 * personal blogs
 * planets
 * other open source / open content planets

IRC channels:
 * #mediawiki-i18n
 * #mediawiki
 * #wikimedia-dev

Organizing regular activities

 * Office Hours
 * Bug Triages
 * Hackathons
 * Translation Sprints
 * Bounties for features
 * Partner / Participate in other open source technology conferences (FOSDEM, FISL, GNUNIFY)
 * Collaborate with other open source projects (Red Hat, Mozilla, Google, Ubuntu, GNOME)
 * Individual email to cultivate feedback
 * GSoC and other programs for developing code and tools
 * Blog posts and technical documentation

Measuring Success

 * 1) Metrics
 * 2) Contributions (documentation, bug reports, online user help, open source fonts)
 * 3) Code
 * 4) Documentation
 * 5) Making more friends
 * 6) Getting more team members

Learning from other projects
We can learn best practices from other open source projects and organizations – translatewiki.net, Mozilla, RedHat and experiences from our own wiki communities.

Mozilla
Mozilla supports any language in principle, but proper repositories and channels for localization are set up only for people who demonstrate technical ability to do localization work. This is similar to what Wikimedia does, but Mozilla's process is very complicated technically and requires ability to edit source files (not just files of string lists) and to commit to source repositories. Mozilla supports about 100 languages. It has a decentralized and distributed structure which is different from that of Twitter. Every language team can use completely different tools and there's little communication between the different language teams. Major volunteer localizers are given some swag and are sometimes invited to conferences. Some people are given mobile phones to test the new mobile platform. Community members can apply to become Mozilla Reps. If they meet some criteria of contribution, they are officially recognized as reps and are assigned a mentor. Most mentors are volunteers, too. Reps have easy access to request swag and budget for events. They are expected to organize and participate in relevant events and spread the word about Mozilla software and Open Web ideas. A special website, http://reps.mozilla.org, is used for communication between reps, for tracking events in which they participate, for sending reports about their activities to the mentors, etc. A group of Mozilla employees coordinate the Mozilla Reps program (also known as ReMo).

translatewiki.net
Translatewiki.net (twn) was designed as an open source platform with a very low barrier to entry for any translator to contribute. The only requirement for joining the twn community is to setup an user account. An environment for any language that has an ISO code is set up in translatewiki.net. A certain number of messages have to be translated in order to be integrated with MediaWiki. Translators frequently help each other in the Support page. When this is not enough, the twn core team (also volunteers) help communicating with developers. New messages groups (Mobile, Narayam, etc.) are sometimes announced on Mediawiki-i18n and Wikitech-l. (NL: Not really as far as I know.) Sitenotices on translatewiki.net are used often. None of these communication channels are used systematically. For e.g. a change in a frequently-used core message is usually not announced.

Translatewiki.net conducts translation rallies and sprints with prizes. Localizers may receive scholarships to go to conferences such as Wikimania for being outstanding Wikimedians, but not directly from twn or the WMF i18n team (is twn among the projects used to calculate activity in the scholarships' criteria? should ask at m:Talk:Wikimania/Scholarships).

Onboarding language representatives
After identifying members who can be effective language representatives, onboarding them with a baseline understanding of the tools and technologies they are working with is essential.

For each language, each language representative should
 * Be subscribed to related mailing lists. We could reuse the current mediawiki-i18n list or create a new language team list for rep communications.
 * Have a translatewiki.net account and understands the fundamentals of translating using twn as a platform.
 * Basic understanding of the following concepts:
 * Translatable components:
 * Core MediaWiki
 * MediaWiki extensions
 * Other tools: Mobile apps, bots, offline readers.
 * Gadgets
 * Templates
 * Banners and announcements on Meta
 * CLDR
 * Have a Bugzilla account and basic understanding of bugzilla workflow
 * Is cc’ed on all relevant existing Bugzilla bugs. This should only be done after the language representative is comfortable understanding the idiosyncracies of Bugzilla and our reporting process.
 * Each representative should also be encouraged to file bugs for more issues.
 * Tracking bugs must be created for every language for which there are multiple bugs. All representatives should be trained to use tracking bugs.
 * Know how to use IRC
 * Be invited to and participate in i18n team demos, office hours and bug triages
 * Has awareness about i18n/L10n issues (such as)
 * Is there a corresponding term for computer terminology in your language?
 * What is the expert level of using localized software in your language?
 * What is expert level?
 * Are you using software in your language or in English?
 * Review the current MediaWiki translation (or Most used translations)
 * Is it complete and correct?
 * Does it need updating?
 * Are there any challenges in translation? Missing documentation? Too much HTML and $1-style params?
 * Does TWN need new software features to be translated correctly?
 * Issues to check specifically: Typing, fonts, gender, plural, custom grammar. For languages with otherwise good support – upgraded typography.
 * Bugzilla bugs must be opened for every encountered issue.
 * Has awareness/Knowledge about Wikimedia projects in your language (or at least Wikipedia).
 * Are there any useful features, like gadgets or templates, in projects in other languages that you want to enable in your project?
 * Are there features in your project that you think that other projects will find useful?

Draft more people who can support this language by making translations, testing language tools, etc. Make guidelines available in a booklet / pdf that can be e-mailed / distributed to representatives

Follow-up
Sustaining our language teams is as critical as engaging language representatives.

In order to do so, regular 1:1 meetings must be held with each language representative. A monthly iteration for the first 6 months and then dropping to a bi-monthly iteration may work for all language communities. At each check-in, the following items are good to touch base on:
 * Status of translations
 * Status of relevant bugs
 * Is the representative getting the needed support from the other language representatives?
 * Does the representative need any help from the i18n team? Are more language representatives needed for this language?
 * Does the representative need any help from a language expert?
 * Current status of various Wikimedia projects for that language
 * The state of the Wikimedia projects in the language. Are the participants using the available language tools? (How do you know that they use it or aren't using it? Just an impression, or do you have any metrics?)
 * Document these updates (by reps - should take no more than 15 minutes)

We should also maintain regular reporting and communicating with language team members. We should continuously iterate and improve team goals via regular retrospective sessions.

Contact us
Give Us Your Feedback!
 * Leave your comments on the Talk:
 * Ping engineering team on IRC (#mediawiki-i18n)
 * Contact Srikanth on IRC (srikanthlogic) or slakshmanan@undefinedwikimedia.org