Translating documentation

In last week’s Polyglots chat (logs) we briefly discussed translating documentation, how it was done in the past and how it should be done in the light of localizing the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme directories and making WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ better fitted for non-English users.

How do we translate documentation now

In the past the Codex has been translated by simply creating new wiki pages and duplicating and translating the content of current pages manually.

The obvious downside of this is that there’s no version control and translators need to check all pages for changes to be able to bring those changes to the translated documents.

Now that Codex is on it’s way to be replaced by the Handbooks, it would be really handy to have those available locally.

So let’s discuss how we can make that happen.

Localizing the handbooks

A couple of options mentioned during the meeting:

• GlotPressGlotPress GlotPress is the translation management software that powers Translate.WordPress.org. More information is available at glotpress.org. – not ideal, @ocean90’s comment explains better:

“I agree, that it should be handled via WordPress itself, not GlotPress, because you can do quicker previews, add translated screenshots etc. We still can/should show the English text on the same page, maybe side by side so we could track out of date translations.”

• Adding the handbooks plugin to the localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ sites so editors can build there own handbooks – the easiest way to go, but would have no version control so will basically replicate the old way of copy pasting the Codex with no way to track changes in the original documents
• Adding the handbooks plugin to the locale sites and including an “Import original content” with an active relation of each duplicate with the original. A way for the editors to pull changes from the original (doesn’t have to be automatic, can be done manually, just as long as editors don’t have to go check every page for changes).
• One option is something @zodiac1978 pointed out is already being done on wordpress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/: “I am doing this for the support pages for wordpress.com. They use a plugin which send you an email for every change (with a revision diff view of the changes). Then we have to manually add these changes to our localised post/page. This could be one way. But much work …”

Let’s discuss the options above and see what ideas the #metai18n team will have too.

Cheers!
Petya

#documentation, #translation