🎉 First of all, thanks for taking the time to contribute to MDN Web Docs’ translated content! 🎉
The following is a set of guidelines for contributing to the translated content of MDN Web Docs, which is hosted within the MDN Organization on GitHub.
Before we go any further, you should be aware that we are only accepting updates to active locales — this means locales that have active community maintenance teams in place to review PRs, fix issues, make updates, etc. Currently the list of active locales is:
fr
ja
ko
pt-BR
ru
zh
(zh-CN
andzh-TW
)
If you want to just find a task and jump in, search by the labels l10n-fr
,
l10n-ja
, l10n-ko
, l10n-pt-br
, l10n-ru
, and l10n-zh
in this repo’s
issues list,
or the main content repo issues
Everyone participating in this project is expected to follow our Code of Conduct.
When contributing to the content you agree to license your contributions according to our license.
A good place to learn about general guidelines for contributing to MDN Web Docs is the Guidelines document. For example, you can find out more about MDN's writing-style guidelines via the Writing style guide.
This repo has exactly the same folder structure, concepts, and commands available to it as the content repo, which holds all of MDN's English content. The main difference is in the setup you need to do before you can start editing. It is mostly the same, but there is a little bit more to consider.
To begin with, get the basic required tooling set up, as described in the content repo Setup section.
Now you need to fork and clone both the content repo and the translated-content repo (this repo).
-
Once the above is done, cd into the content repo.
-
Run the command
yarn install
to fetch the latest packages and get the local MDN testing environment set up. It is also recommended that you runyarn install
before every update you do to the source, to make sure you have the latest packages. -
Next, create an environment variable called
CONTENT_TRANSLATED_ROOT
containing the path to the translated-content repo’sfiles
directory. You could do this for a single session like so:export CONTENT_TRANSLATED_ROOT=/path/to/translated-content/files
But you’ll have to newly-set this every time you open up a new terminal window. Instead, you could put the environment variable setting in an
.env
file in the root of your content repo. This is most easily done using the following command:echo CONTENT_TRANSLATED_ROOT=/path/to/translated-content/files >> .env
(the
.env
file will be created for you if it does not already exist.) -
Now you’ve got this set up, enter the command
yarn start
to begin the local testing server running atlocalhost:5000
.
Over in the translated-content repo, decide what change you want to make, and then:
-
Create a new branch to make your changes in.
-
Switch to your new branch and make the changes you want to make. You can keep going back to
localhost:5000/<your_locale>
(e.g.localhost:5000/fr
for French) to test your changes and make sure the content looks how you want it to look. -
When you are satisfied with your changes, create a pull request and one of our review teams will review it.
-
Once the pull request has been merged, the edition may take up to 48 hours (daily build and CDN caches). To see if your change has been deployed, you can check on What's Deployed.
For more information, we’d like to suggest that you go to the content repo and read its README file, particularly to learn about fundamental concepts, pull request etiquette, and common actions such as adding, moving, or deleting documents.
It is the responsibility of the active community maintenance team for each
active locale to keep up-to-date with reviews of pull requests and handling
issues filed against that locale. You can filter the relevant pull requests and
issues for each locale using the relevant label — l10n-fr
, l10n-ja
, l10n-ko
, l10n-pt-br
, l10n-ru
, and l10n-zh
.
The review teams for each locale are:
- Brazilian Portuguese (
pt-BR
) content — the @yari-content-pt-br team, which consists of: - French (
fr
) content — the @yari-content-fr team, which consists of: - Japanese (
ja
) content — the @yari-content-ja team, which consists of: - Korea (
ko
) content — the @yari-content-ko team, which consists of: - Russian (
ru
) content — the @yari-content-ru team, which consists of: - Chinese (
zh-CN
andzh-TW
) content — the @yari-content-zh team, which consists of:
Active community maintenance teams are expected to keep their locales maintained and reasonably up-to-date. This means:
- Reviewing and actioning all pull requests within 2 weeks.
- Triaging and fixing all actionable issues within 1 month.
- Making reasonable progress on keeping MDN’s Tier 1 content (definition TBD)
synchronized with the
en-US
versions. This means some progress should be made each week, e.g. updating an article to be in sync with the English version, removing or fixing a bad quality article…
If no progress is made on a locale in these areas within 1 month, the locale will be considered inactive, and edits will stop being accepted.
If you want to promote a currently-inactive/frozen locale to Tier 1, meaning that it is activated and can then be edited, you need to put together a community maintenance team. This requires:
- A team lead who will be the communication point between that team and the MDN core team, and have overall responsibility for the team.
- At least one other member, so that one member can review another member's work.
- A place to discuss this team's localization work. This can be a Telegram group, Matrix chat room, or whatever the team thinks is best.
If you want to find out more about our community maintenance teams, see localizing MDN. If you want to ask questions or talk to us about forming a new community maintenance team, see ask for help.
Before unfreezing the Tier 1 locales, we made an update to synchronize all the
localized document tree structures with the en-US
tree structure (English
slugs only), to make the documentation easier to manage. This resulted in two
new buckets of documents being created for each locale, existing as
subdirectories of each local folder:
orphaned
— documents that are not associated with any parenten-US
page.conflicting
— documents with duplicate translations in existence (e.g. localized once under the existingen-US
slug, and then again under a localized slug). The duplicate(s) are put in this folder.
Active locale maintenance teams are invited to spend some time exploring the orphaned and conflicting documents, to see whether any of this work is worth keeping (either adding to, or merging with an existing document in, the main tree), or whether it can just be deleted.
We run a GitHub action every day to update the localized documentation and keep
it in sync with the en-US
tree structure, for example if documents are deleted
for, or moved to a different location, in the tree.
When a synchronization occurs:
- Tier 1 (active) locale maintenance teams are given two weeks to decide what to do with the affected documents in their locales to keep things in sync.
- Tier 2 (frozen) locales have the affected documents deleted/moved immediately.
Note: Conflicting docs are often created during the sync operation when en-US
documents get merged — for example if Foo/Bar
becomes just a section inside
Foo
, and we redirect Foo/Bar
to Foo#Bar
. This will result in a conflict
as the sync job tries to move the translated Foo/Bar
to Foo
according to the
redirect, but Foo
already exists.