Starting a new MDN localization

Localizations of MDN content help extend MDN’s reach to many more web developers and potential web developers than merely those who can read English. Therefore, localizations are a vital part of achieving MDN’s mission.

Requests for new localizations on MDN are evaluated on a case-by-case basis, and must meet some minimum requirements. Additional factors that are considered include the number of speakers of the language, and the proportion of that group who also read English. We do not have strict rules about these numbers, but priority will be given to locales that significantly extend the reach of MDN. A language with a large population of speakers who do not read English will be given higher priority over one with a small speaker population where many of them read English.

Minimum criteria

The minimum criteria for adding a locale to MDN are:

• An active Mozilla localization community for the locale exists outside of MDN.
• A designated localization leader for the locale has committed to leading the localizing effort.
• The locale for MDN has been added in Pontoon, and the community has translated at least 50% of strings.
• A staff member has agreed to mentor the localization leader (based in part on the additional factors mentioned above, as well as team workloads).

Process to start a localization

Starting a localization is not a single event, but a process with the following general steps:

1. Be a member of an active Mozilla localization community. If the Mozilla community for your locale is not active, work on building up that community before expanding it to include MDN.
2. Reach out to the MDN community to share your intention of starting a new MDN localization. (For example, join the MDN-related mailing lists and the #mdn IRC channel on irc.mozilla.org.) Core members of the MDN community, including MDN staff, can advise you on whether your proposed locale seems like a good fit for MDN.
3. Add a section for your language to the list of localization projects, and include anyone else who is planning to work on it.
4. Submit a bug in Bugzilla to request activation of your locale for MDN in Pontoon. This bug should be in the "Mozilla Developer Network" > "Localization" category. A Pontoon administrator must do this activation.
5. Work with your localization community to translate MDN UI strings in Pontoon. Don’t proceed to the next step until you have at least 50% of the strings translated. Keep communicating with the MDN community about your progress.
6. Submit a bug in Bugzilla to request that the locale be added to the list of available locales on MDN. (Same product and category as the bug in Step 4) Indicate who will take the role of MDN localization leader, to be a point of contact between the MDN localization group and the rest of the MDN community. Usually, this is the person who submits the bug. In order for your request to be accepted, a member of the MDN staff must be willing to mentor the localization leader, so good communication up to this point will pay off if you can show that:
   1. Your Mozilla localization community is active, and has the organization and interest need to sustain working on MDN.
   2. Your locale is a good fit for MDN.
   3. As a localization leader, you are easy to work with and responsive to feedback.

Organizing a localization project: MDN mechanics

The basic structure of the page hierarchy in each of the localizations of MDN should be essentially the same. In general, you should try to maintain the same hierarchy of pages as the en-US (English) locale, so that each page in each language corresponds to a similar page in each locale.

You are welcome to link to external local pages, write your own articles, and translate everything from the English wiki. If you do decide to write your own articles, it would be helpful if you could provide an English translation for the English wiki so it can then get translated into all of the other localized wikis.

In adding local resources, you should keep a neutral point of view; that is, you shouldn't promote a particular perspective, and should instead simply provide the facts as best as possible (see information about the NPOV rule on Wikipedia). You should not link to commercial sites (like paid courses, web design companies, etc.). You should promote open standards and cross-browser compatibility over closed or proprietary methods wherever possible.

There are lots of great tips from various existing translation teams; you should feel free to adopt any of these ideas you choose. In addition, please feel free to add your own suggestions as well. See this template in the Spanish wiki for an example.

• Use a macro to identify articles that are in the process of being translated. The macro should provide an information box that includes a link to the original version of the article. You may also wish to use page tags to indicate pages that need more translation work. This helps track articles that are in the process of being translated.
• Use a macro to include articles that need to be translated in article lists with a flag or marker next to them indicating that the article hasn't been translated yet. This is a way to advertise important articles in need of translation. See this template in the Spanish version of MDN for an example.
• Use the "Needs technical review" and "Needs editorial review" flags, to mark articles that have been translated but should be double-checked for technical and grammatical accuracy.
• Use the "junk" tag to mark pages that need to be deleted. Since only admins have access to delete articles, this provides a way to mark that an article is obsolete until the admins get the page deleted.
• Be sure to include translations of these MDN "how to" pages, and include additional pages as necessary to explain your localization team's policies and practices.

To find help with your project, be sure to ask around on the dev-mdc mailing list, the #mdn IRC channel, and other MDN-related discussion areas. See "Join the MDN community" for pointers to community discussion channels that will help you find others interested in joining your localization team.

You may also be able to find others interested in helping you by attending local Web development events, at your local hacker space, and the like. Be creative!

Organizing a localization community

Work with any existing Mozilla localization communities

Experience has shown that the most active and successful localization communities on MDN are extensions of existing Mozilla localization communities. If you’re interested in starting a localization on MDN, and you’re not already in contact with the Mozilla community for your locale, look them up and get in touch. You’ll find some great folks with experience to share about Mozilla and localization.

Get lots of people involved

We’ve also seen that the more people are involved in a localization effort, the more likely it is to be self-sustaining. People come and go in a localization effort (like most things in life). The more people are involved, the more likely it is for the group to sustain through those changes. Efforts that are started by one person or a small group usually do not remain active longer than the initial members. Therefore, a big part of starting a localization effort is recruiting enough people so that the group keeps going even when some people drop out, as they inevitably do.

Meet regularly, in person or online

Meeting regularly with other localizers can be a great way to build a sense of group cohesion, so that people want to keep participating. Meeting face-to-face is great if everyone is located closely together enough to be able to do that. You can meet virtually online if your group is spread too far apart to meet in person. Meeting on a regular schedule, such as once a month, is also important, so that members of the group can plan to attend. Some localizers may contribute only during a meet-up, and not at other times.

What to translate first

MDN has thousands of articles in many different topic areas. Maybe you are passionate about a particular topic — by all means, start there! But if you're looking for starting points, here are some suggestions:

• Pages tagged "l10n:priority"
• Learning Area guides
• The JavaScript Guide
• HTML reference pages for common elements
• CSS docs

For some locales, localizers consider guides and tutorials to be a higher priority than reference pages. Web developers can often figure out code syntax from the English version of a page, even if they don't know much English. But learning new concepts is much more comfortable in one's native language. So, it may be important to translate tutorials first.

Policy

All materials created and translated for the MDN should follow our Copyright and Licensing Policies.

If you encounter problems of any sort—technical, policy, or other—please contact the MDN admin team.