Account confirmers, canmove, Confirmed users
2,357
edits
Contribute/L10n: Difference between revisions
Jump to navigation
Jump to search
→Background Info
| Line 137: | Line 137: | ||
Our main focus/goal in this next quarter, in terms of engagement, is to increase the size of each L10n community. We're attempting to do that by lowering the bar to entry (through new tools development and clearer doc), creating a mentoring program (like World Ready), and providing a more centralized and clear platform for project tracking and joining the communities (elmo project). ''Jeff'' | Our main focus/goal in this next quarter, in terms of engagement, is to increase the size of each L10n community. We're attempting to do that by lowering the bar to entry (through new tools development and clearer doc), creating a mentoring program (like World Ready), and providing a more centralized and clear platform for project tracking and joining the communities (elmo project). ''Jeff'' | ||
==Additional info== | |||
This section could also be titled, "Why our program won't allow us to track and individual's l10n contributions." In this community profile, I want to point out some of the l10n drivers' approaches to managing the l10n community, its efforts, why this inhibits our ability to track their lifecycles, but why we'd like to keep it this way. | |||
===Self-governing=== | |||
We largely allow l10n teams to govern themselves. Each team creates its own organizational structure, manages assignments and tasks according to its needs, and selects where and how it would like to contribute. We teach them correct principles and provide a solid infrastructure, they do govern themselves. At times we step in to re-teach and remind, as well as provide them with new information should that info affect their workflow. | |||
Here's an example of how self-governing teams make it difficult to track contributions. Hg is a difficult tool to learn. It's also challenging to aqcuire the necessary permissions to commit and push to product repositories. For these reasons, many localizers prefer that only one team member have hg commit access. This means that while the whole team may have participated in producing the localized build of Firefox 15, the only statistical evidence of contribution is linked to the ID of the localizer who performed the hg commit. False data like this is common, however, we would prefer it to requiring that everyone working on localizing products learn hg and gain commit access. You know what they say about too many chefs in the kitchen. | |||
===Freedom of choice=== | |||
You may have noticed that we have a large selection of l10n tools that our available to our localizers. While this does create interoperability problems for us, it also allows many l10n teams to work in whatever way they choose. In addition, few l10n tools contain PM utilities or metrics utilities. We still prefer our l10n teams have the freedom to choose because it enables more people to get involved in l10n without any technical ability requirements nor internet access requirement (both of which could halt the progress of several of our l10n teams). | |||
Our primary division amongst l10n tools is online vs offline: | |||
;Online | |||
L10n teams using online tools do so for the following reasons: | |||
*Little to no technical understanding is needed. | |||
*Easier to collaborate when there's a good internet connection. | |||
*Provides a central "beta" repo in which suggested translations can be reviewed, voted on, and approved before they're pushed to the locale's repo. | |||
;Offline | |||
L10n teams using offline tools do so for the following reasons: | |||
*More challenging, gives a sense of "hacking" a localization. | |||
*Only option available for regions without a good internet connection. | |||
*More portable, as all work is stored locally. | |||
*Allows team to determine which l10n tool they want to use. Some teams use full CAT (Computer-Assisted Translation) tools which allow them to create and maintain terminology and translation memory all in a single tool. Others prefer to use the command line and a text editor. | |||
===Plethora of projects=== | |||
There are many, many projects to localize. A localizer has the following l10n project options when they join Mozilla: | |||
*one or more products, | |||
*Mozilla web content, | |||
*SUMO articles, | |||
*MDN articles, | |||
*and any and all marketing campaigns that come down the pipeline. | |||
Each of these projects has a different workflow, and even sometimes fragmented workflows depending on whether the localizer is able to work on- or offline. Even then, it's hard to determine where the division of responsibility lies for localizing projects like SUMO or MDN (Who monitors the localizer's activity for either project, the l10n drivers or SUMO/MDN? Should the product team be monitoring a localizer's activity if they're localizing product or should we?). We would prefer, however, that l10n teams determine where the locale's needs lie and that they ensure that a localizer is participating in the projects they're passionate about. That being said, the obvious consequence is that we're unable to track a single localizer's contribution through every single possible contribution pathway. | |||