HelpHub Localisation Plan

Hi! This is Jon from docs team. This post outlines our plan for localising HelpHub for Rosetta sites. HelpHub is currently live on English site and can be accessed from (e.g. ).

We’d like Polyglots team’s input to make this translation as smoothly as possible.


At  WordCamp Europe (Summit) we discussed the localisation of WordPress systems such as DevHub and HelpHub.

We recognised that GlotPress was not great for long-form translation and we evaluated the possibility of actually re-engineering GlotPress (or at least to work for it. But this is a huge undertaking and it may involve formalisation of the whole of’s translation.

So it was indicated it might be best for HelpHub to look at translation out of GlotPress.

Therefore HelpHub was designed as a stand-alone plugin that could be activated at numerous places such as Rosetta sites.

Plan Phases (Proposal)

Phase 1


  • Test HelpHub localisation on one locale’s Rosetta site.
  • Migrate existing English content, but update notification/diff will not be available yet.

Candidate Locales

  • Japanese, since they maintain their own Codex site with a large number of docs
  • French (France), since they want to set up a fr_FR Documentation team (~10 volunteers for the moment)


  1. Activate HelpHub plugin on Rosetta [Meta]
    1. Need Meta help as Rosetta sites are likely on a different network
  2. Migrate English content over (without activating HelpHub’s home interface) [Locale Team]
    1. Explore automated process (but unlikely due to infra)
    2. At this phase, this may need to be a manual process
    3. If manual process, adapt and refine tracking system of migration designed by Docs Team
  3. Translation by locale team based on English contents [Locale Team]
  4. Possibly re-take related screenshots in locale language [Locale Team]
    1. Create a list of needed screenshots so other locale’s volunteers can contribute as needed
  5. Development work to link English and localised content [Meta]
  6. Define a syndication plan to track updates of the English version and trigger notifications to localisation team [Meta] [Docs]
  7. Activate HelpHub’s home interface on the Rosetta (just this test locale) on /support [Meta]
  8. Adjust the documentation links on the Rosetta site from Codex to HelpHub [Locale Team]
  9. “Push” forums link back to /support/forums [Meta]
  10. Redirect locale’s version of Codex or support materials to locale HelpHub (e.g. [Locale Team]
  11. Establish communication channel between English HelpHub and locale teams [Docs] [Locale Team]
  12. Write a blog post on the locale news page to announce the move of user support resources [Locale Team]
  13. Do a retrospective and identify pain points [Docs] [Locale Team]
  14. Refine Phase 1 Plan for other locales based on first candidate [Docs]

Phase 2


Roll out the localisation to more Rosetta sites.


  1. Enable HelpHub plugin on active Rosetta site (individual sign up) [Meta]
    1. What happens to teams without active volunteers? Maybe we’ll show English docs on their site
    2. Explore the possibility of showing machine-translated content
  2. Allow main to reveal that there are other locales’ HelpHubs/Support [Meta]
  3. (To be determined)

#documentation, #helphub, #rosetta

Hi @ocean90, We would like…

Hi @ocean90,

We would like to be active in our local rosetta site, may we request forum and team P2-blog added to

Thank you and kind regards!

#request #forum #rosetta

Hello @ocean90 We wold like…

Hello @ocean90

We wold like a forum and a P2-blog added to

Thanks in advance.

#da_dk #request #forum #rosetta

Local sites content – let’s gather the data

For a while now we’ve been talking about something we call Rosetta outreach. As most of you know the WordPress Rosetta sites are the local sites for WordPress, associated with a specific locale. Example: (Spain), (Romania), (Bulgairia), etc. A full list of the WordPress Rosetta sites can be found on our Teams page.

Historically the people who took care of translations also took care of updating the content of the Rosetta site. But as translation work grows and local communities grow, the roles on a local team are now separated and we can have translation teams (who take care of localizing WordPress) and editorial teams (who publish important WordPress news on the local sites in their native language).

Since having an editorial team is new, but having local teams who organise meetups and WordCamps outside the localization efforts is not that new, the Rosetta outreach project aims to create a bridge between the translation community and the local community teams in order to provide more value to WordPress users all over the world in their own language.

Objective: provide more valuable localized content on local sites

To achieve that we’re focusing the initial efforts on three main things and we need the help of the existing teams for both:

  1. Gather data about the current status of local Rosetta sites
  2. Reach out to event organising local teams to invite them to join the local editorial teams.
  3. Figure out a way to attract people from outside both the polyglots and community teams to become local .org editors

What content should a complete Rosetta site have?

Each team can decide what content their local site should have, but after several discussions during weekly meetings this is what the team recommends:

  • Translated announcements for each WordPress release (the content of, but localised)
  • Updated showcase with fresh samples of good WordPress work in your language (be careful about the guidelines here, doing a call for showcase examples on a broader community level is your best approach here)
  • Event announcements – local meetup announcements, local WordCamp announcements, calls for speakers, sponsors, volunteers and what not for local events
  • Anything that you feel needs a local community discussion or is an important local topic related to WordPress

What do you can do to help?

  • If you are a Locale manager or a part of a local team, please fill out the data about your local Rosetta site in the “Data” tab of this spreadsheet
  • If the content of your local site is not regularly updated, you can reach out to event organisers in your country and talk to them about being editors in your local Rosetta site and publish content like:
    • WordCamp announcements
    • Meetup announcements
    • Create an events/meetups page
  • If you don’t translate and publish WordPress release announcements regularly, you can think about creating a page on the website that tells people how they can get involved with contributing content in your local language.
  • Volunteer for a regional outreach – you can help us reach out to local teams whose sites are a bit stuck and find contributors who would be willing to help update the content on their Rosetta sites.

Sound interesting? Leave your thoughts in the comments and let’s do this.



#local-sites, #local-sites-content, #rosetta

A “Translate in locale name” page for all Rosetta sites

I’d like to suggest that we recommend adding a “Translate in [locale name] page to all Rosetta sites that don’t already have one.

I worked with @rabmalin, who recently joined the Nepali team, to help him create a page for

I have created a general template for the page after that and I think it should be included in the instructions about Rosetta sites in the handbook for all new Editors/General Translation Editors and GTEs of existing locales that don’t already have one.

It goes without saying that each  team would have the autonomy to modify/include/exclude content from this page or not use the template at all. But like with the standard slide deck about translating WordPress in your language, it can provide a general guideline for new contributors about communicating their transaltion effots.

The “Translate in [locale name] template for Rosetta sites is available here – anyone can comment.

When reviewing the template, let’s try and answer these questions:

  • Have we included all the necessary content for a new contributor to understand how to get involved. If not, what’s missing?
  • Is the page easy to read/understand (when you think about translating it into your language? Can we improve the phrasing so it can make more sense when translated)


@sam @ocean90 Can we think of an option to add this or a version of it as a default page in a Rosetta site next to the Contact and Welcome pages?

With the current situation, there’s a very slim chance of a site existing without being tied to a Translation project. So I think it makes sense to help new locale maintainers by providing this page by default.



I have completed the translation of the following…

I have completed the translation of the following language:
Locale: Pashto
WP Local: ps
GlotPress: ps

Can i please get an admin access to WP Rossetta portal as the current page has too many translation errors, i have tried to contact the current admin but i haven’t got any response back. currently i do have validator privileges on that portal but that does not allow me to edit any of the contents.

Your help in this regard would be extremely appreciated.

M Sadat

#pashto-language, #request, #rosetta, #translation

Notes from the polyglots chats on Jan 14th an Jan 15th

Locale stats

We got 11 locales updated to 4.1 last week!
We now have 50 locales that are up to date.
Ten are still behind one major version so I’ll write a post on make/p2 this week and ask the validators for help
We also added one new locale last week, so say hi to @zayedbaloch who is the new validator for Balochi

Technical stats/report by @ocean90

  • We used to have over 9,5 million translations, which was a bit too high.
  • It’s now reduced by 50%, because we had many orphan and broken projects/translation sets
  • 80% were the result of failed branch processes, so nothing is lost
  • The new number is about 4,5 million. We should notice a small performance increase. Maybe.
  • Local details pages are fixed, issues like missing projects are gone now.
  • “Sub-sets”, formal/informal translation sets, now have its own details page, for example
  • We now also have natural sorting for WordPress/BuddyPress sub projects: (left sidebar)
  • The “New to” message is now (really) stored in a user meta, just for @sergeybiryukov.

Translation sprints / hack days / contributor days

May be different types of events – support hours and translations sprints. Support hours happen regularly and translation sprints are tied to a release of a WP version or to a specific project – like BuddyPress, bbPress or some of the other plugins. Mostly for locales that have already completed WP Dev.

Finding new validators, some simple steps to take:

  • Speak at your local meetup about translating WordPress and joining the team
  • Improve your local Rosetta site
  • Improve docs and getting started guide
  • Orientation for new translators/validators?



#new-contributors, #rosetta, #stats, #weekly-meeting-notes

WordPress 4.1 instruction manual

WordPress 4.1 instruction manual

Hello polyglots! In the next 3 hours or so, @johnbillion will be starting the release process (in #core in Slack). Please make sure you are 100% translated for WordPress 4.1 and all subprojects, and also do not forget about the Akismet project.

I’d expect a release somewhere around 1600 UTC, but for most locales, the release process is now automated. Please read on.

Part 1, Language Packs

If you are 100% translated at the time of 4.1’s release, a language pack will be generated for you. This is a ZIP file consisting of PO and MO files only, and is used for the language chooser during the install process, and for the language switcher on the settings screen.

If you become 100% translated some time after 4.1’s release, a language pack will be generated for you once the script is run. This will be around every hour.

If you are 100% translated, a language pack has been created, and then you modify a translation to fix a typo or whatever, a language pack will be regenerated for you once the script is run. Please do not do this with unnecessary frequency, as it triggers an update across all WordPress sites.

Part 2, Release Packages — IMPORTANT CHANGES AHEAD

release package is what you’re used to building using the form on Rosetta’s dashboard. This is a ZIP file consisting of WordPress in its entirety, along with PO and MO files for core, the PO and MO files of default themes and Akismet, and any custom changes you have.

Do you have custom changes? For the purposes of this exercise, your locale falls under one of these four groups:

  • You have never had any custom changes and is entirely empty for your locale.
  • You have no custom changes for 4.1.
  • You have minor custom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php.
  • You have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications.

Here are the details on each:

  • If you have never had any custom changes and is entirely empty for your locale, you do not need to do anything. Your release package will be created automatically for you. An example locale is en_GB.
  • If you have no custom changes for 4.1, please ensure you have an empty branches/4.1/dist or tags/4.1/dist directory at (Having an empty trunk/dist directory does not help you.) You do not need a dist directory if branches/4.1 or tags/4.1 is empty. An example would be nl_NLYour release package will be created automatically for you.
  • If you have minor custom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php, please ensure these files exist in a branches/4.1/dist or tags/4.1/dist directory at (Having your stuff in only trunk/dist does not count.) An example would be eo or fr_FRYour release package will be created automatically for you.
  • If you have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications, you will need to create a package via Rosetta as you have done in the past. For this, We are phasing out the ability to ship any customizations beyond license, readme, and wp-sample-config.php. This means you need to reach out to the WordPress core contributors to fold your modifications into WordPress core. You can start this process by creating a Trac ticket.

To summarize:

  • If all you have is a license, readme, and wp-config-sample.php (or no custom changes at all), everything will be automated for you for WordPress 4.1 if you follow the instructions above. Both language packs and release packages will automatically be created once 4.1 is announced. If you are not at 100% at that time, then language packs and release packages will be created when you reach 100%. If you are later modify a translation (to fix a typo, for example), your language pack and release package will be regenerated.
  • If you have extensive custom changes, you will need to manually create a package via Rosetta as you have done in the past. This option is being phased out in 2015.


If you go to the releases screen on your Rosetta dashboard, you’ll see a new notice that explains what the system thinks your status is. If you have any questions, comments, concerns, or issues, please comment here or find me or @ocean90 in #polyglots on Slack.

If your locale is currently eligible for automatic creation of release packages (which includes being at 100%), you’ll find an RC3 build generated from tags/4.1-RC3 waiting for you on your dashboard. Please inspect these ZIPs. Those locales are: az, bs_BA, de_DE, en_CA, en_GB, eo, fi, fr_FR, it_IT, nb_NO, nl_NL, pt_PT, ro_RO, and sv_SE (zip links).

#4-1, #announcement, #rosetta

There’s been a snafu on Rosetta sites —…

[Updated 9:02 GMT] There’s been a snafu on Rosetta sites — I managed to delete the released zip packages for about half of the locales. There were a few minutes where 4.0.1 was not available to download for some languages, and a few hours where older releases were not available. Everything has been restored from backups. You have nothing to worry about!


Notes from the Rosetta sites discussion at #WCSF Community Summit

Hey everyone,

As you already know last week following WordCamp San Francisco there was a Community Summit followed by two contributor days to give Make teams the chance to work together and discuss important subjects.

In the next couple of days I will be posting my notes from all of the discussions and meetings we had so all of you are up to date with what’s been said and done.

Starting right now with the first discussion of the Community summit, suggested by Xavier.

Who was there: Andy Christian, Andrew dela Serna, Birgit Olzem, Catia Kitahara, Konstantin Obenland, Marko Heijnen, Mayuko Moriyama, Petya Raykovska,Rafael Funchal, Sam Sidler, Xavier Borderier,

Rosetta sites and Local Communities

We tried to see what different local communities are doing with their local sites and mark what improvements are needed for Rosetta sites to enable communities to grow.

Right now a lot of the more active communities just use their Rosetta sites for downloads of the localised WordPress version because of all of the limitations. Rosetta administrators/editors and validators get access to approve strings for local translations but can’t actually change the website, just add pages, write blog posts and release translations.

We discussed different tools Rosetta sites need to be a viable tool for local communities: 

Desired Rosetta extensions

What kind of extensions do communities need for Rosetta: 

  • A public feed aggregator (aka “planet”)
  • Event calendar / community events
  • Job board
  • Documentation (to replace Codex and work with
  • Community map
  • Team list – can be public or not
  • Local community pages (P2s)
  • Widgets for homepage

External Community websites

Some communities have put a lot of work and effort into external community websites because they can not extend Rosetta sites. Some examples are Germany, France, and Portugal.

No community will be forced to move back to the local Rosetta site, but an effort can be made to provide more tools and options for Rosetta sites so communities are actually willing to move back. 

If that becomes the case, there needs to be an easy way to transfer the existing content or at least have a plan on what will be done with the external sites so all of that content is not lost, perhaps by archiving.

Check how it works for most of the active communities:

  • How should current community sites be integrated?
  • What different user roles will be needed in order to facilitate adding 20+ more validators per locale?
  • How can migration of community sites happen?
  • There has to be a plan for if you want to move your site. Let’s check if .org can host it.

With the plans of themes and plugins being localized, each locale will probably need at least 20 validators in the future (with plugins and themes in there).

User roles

With themes and plugins coming, there will need to be some more user roles for Rosetta sites and probably some clear separation between translators and community leads. 

A new “super validator” role (name-pending) will be needed to ensure quality of the translations for the top projects (WordPress and the projects that are already in GlotPress plus the top 25 plugins and themes).

And the project will need to bring in a lot more validators to be able to handle translating plugins and themes. 

A super validator will be needed for adding validators and removing validators that are not performing well. We need to be more sensitive about this thing. Translators need to be trusted.

Consider the forums for the locales that want it. Consider P2s and news blogs. We need to consider all of the features that are needed and then pick up roles that make sense.

Expectations for external links and Showcases on Rosetta sites:

  • Showcase:
    • Validators cannot have their websites in the showcase.
    • Community sites are generally not allowed in showcases, because they’re linked to elsewhere on the site.
    • Explicit sites are not allow in showcases.
  • Community Sites (when linked to from Rosetta sites):
    • Must have a prominent link back to the relevant Rosetta site (e.g.,
    • Cannot have advertising on them. One exception is that we allow a “hosted by” graphic/link if a company is sponsoring the community site (but no money can exchange hands).
    • Donate links are not allowed unless they go to the WordPress Foundation.
  • Advertising is not allowed on Rosetta sites, including advertisements for hosts, validators, translators, or other forms of advertising. Sites are allowed to list validators and translators with links to the blogs on a separate page (say, “About”).
  • Private information (phone numbers, email addresses) is not allowed on Rosetta sites.

#community-summit, #external-community-sites, #local-sites, #rosetta

It’s possible to have an archive page for…

It’s possible to have an archive page for the showcase in rosetta sites?

#request, #rosetta, #showcase

Some images returns 404 in http ja wordpress…

Some images returns 404 in
I guess this may be related to “Rosetta and .org installs are now merged.”(

ping: @nacin

#ja_jp, #rosetta

There have been some underlying infrastructure changes to…

There have been some underlying infrastructure changes to all Rosetta sites. This shouldn’t break anything, but if you notice anything unusual or broken, please let me know. These changes don’t make any difference at the moment, but will make it a lot easier for me to implement a number of things in the coming days, weeks, and months.

This is what caused images and downloads to break the other day, as discussed here. This was my fault and I’m sorry about that. As Nikolay pointed out, this had no effect on any new installs (language chooser) or updates — just downloads directly from the individual websites. Anyway: that initial deploy was un-done, the problems were diagnosed, solutions were put in place, and then we re-deployed it a few minutes ago.

#rosetta, #status

We’ve just finished translating WordPress into Vietnamese and…

We’ve just finished translating WordPress into Vietnamese and I’m trying to release updated translations and an updated version of WordPress to

I’m confused about the process. There’s a tool in the backend that allows me to release updated translations, but the version of WordPress that’s included in the package is old. I think it’s coming from here: Those files are very old. contain redirects, and in general need to be gutted. I’ve attempted to clean this up with my .org username but I don’t have access.

What is the proper way of releasing new translations + WP packages? Is it safe to just delete that entire /dist/ folder so that WordPress is only pulled from the English version of /trunk/ for now, along with the translation files that we’ve done?


#request, #rosetta, #vi

I can’t post new posts @ sv wordpress…

I can’t post new posts @ Getting “Send for review”

#rosetta, #sv_se