• Date: June 12, 2024
• Place: During Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. at WCEU 2024

Attendees: @amieiro  @javiercasares  @glycymeris @battelfred  @estelaris @cbringmann @chanthaboune @nullbyte  @milana_cap  @tobifjellner  @courane01 @emmaht

Agenda: https://make.wordpress.org/docs/2024/06/10/localization-and-translation-of-helphub-during-wceu-2024/

Goal

The goal of this project is to create a process to facilitate and simplify the translation of 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/ documentation into other languages. Perhaps in the future, the same process can be either replicated or used as a starting point for other teams to translate their documentation. 

What does MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. need to prepare Rosetta sites for the documentation page? 

Ticket discussion:  https://meta.trac.wordpress.org/ticket/7637

@estelaris reported that the Meta team doesn’t know the scope of adding this page to Rosetta sites currently, as the requirements differ from site to site. 

There are teams like JA(Japanese), FR (French), and IT (Italian) that have a great deal of the documentation already translated but still need the new site maps. Others, like BG (Bulgarian) and RU (Russian), still connect documentation to Codex. LT (Lithuanian) does not have either a support or documentation page. These are the few teams that met at WCEU or have been in touch with the docs team at different times.

Meta tickets will be opened for the sites linked to Codex to make sure everything is documented. It is important that the existing articles in a local language do not get lost.

@estelaris is writing documentation to help the meta team. This documentation includes the steps taken while the global documentation page was created and a spreadsheet with the redirects.

Another issue to consider is that this process will need a dedicated meta team member due to the amount of work involved.

Cross-team communication

The teams working on this project are GlotPress, Docs, Meta, Training, locales, and operations. We are communicating through the  #polyglots-multilingual-community on Slack.

Any updates or related posts will be posted on the Team Updates Make blog and cross-post to the #docs, #meta, #polyglots, and #training Make blogs.

Is the marketing involved in this project?

Not at the moment. The main goal is to focus on one team. Hopefully, the marketing team and other teams can replicate the translation processes developed by this project.

Other projects

Other projects that require translation are the Developer Resources and the Developer’s blog, which are in a subsite under developer.wordpress.org. Meta will need to resolve a very specific issue related to the developer site and that is the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to be used in Rosetta sites. It was mentioned at the meeting that translating the Developer blog is important because it provides timely information for developers.

Then there is Learn. The content from Learn is uploaded directly to the Learn site, and it is not linked to GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. The training team also stores all languages on one site at this time, and Sensei LMS is not yet compatible with content in multiple languages. 

For the Rosetta sites, the scope for the new page /documentation/ was discussed and needs more feedback, this team should continue working with Meta to understand how to add the developer and other pages. 

What is the process?

These are the steps we would like to test:

1. Create the project in GitHub.
2. Translation and revision that all the content from the article is there
3. Add the translation to GlotPress
4. Review and approval by GTEs
5. Post on the local documentation page

As an example, the Spanish team is translating articles from the project created in GitHub [ES] Traducción y localización de la documentación de usuarios finales. The French team has a different process. Until we have the correct tools to work on long translations, a local team should be flexible in its work.

GlotPress

GlotPress is used only to translate strings for themes, plugins, etc., but doesn’t have the capacity to translate long blocks of text. One way could be for each paragraph to be treated as a string.

The GlotPress team needs to create a 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 to import data from different sources and another one to export this data, create new projects, and define a structure inside translate.wordpress.org. Once 90% of the content has been translated, it can be moved to a page.

Screenshots and videos should come from the local site. Jeff Matson built a tool that could automate updating the screenshots with a new version, but the code source and the state of the project are unknown. @courane01 will find out more.

Tasks

Docs team

1. Finish the documentation for https://meta.trac.wordpress.org/ticket/7637
2. Continue working with the translation teams to add their redirects

GlotPress

1. Evaluate what is needed to translate long blocks of text in GlotPress.
2. Creating a system for segment labeling.
3. How to maintain versioning of previous translations.
4. Which URLs work better with GlotPress, English only or English + other language?

Spanish team

1. Translate at least 20 pages to start testing GlotPress and advise the GTEs.

Operations

1. @cbringmann will coordinate any extra developer time needed.

Thoughts on GlotPress and GitHub

• If using GitHub for versioning, is there another tool for labeling how the segments have been changing
• Split a page into segments to maintain versioning and keep a record of previous versions.
• Reuse translations as much as possible to avoid additional efforts.
• Keep segments before and after the ones that are being translated to create context and meaning. That feature is part of professional translation software.
• GlotPress doesn’t have this capability, perhaps changing the data format from the GetText infrastructure.
• The Spanish team is finishing a GitHub contributor handbook for beginners. This will help new contributors learn to work with GitHub.

• The workload is heavy on the reviewers; the documentation team has to decide which tools we will use for translation.
• The workload for the GTEs will not increase significantly because everything will be in GlotPress.
• All the text must be on one page, and the paragraphs must be in order.
• During the translation, we need to compare the English and Spanish/other language versions. There is a problem with that option. When you enter a paragraph, it gets an ID. The problem is that when the English version is updated, we need to add more metadata to the original strings. We will investigate more about this issue.
• Another issue with GlotPress is that it is string-based. If you have a string that says “no,” it will be translated the same everywhere. This is an issue because “no” can mean several things. It could be the opposite of yes, or it could be used as a shorthand for “number,” or it could mean something else.
• The same concern shows in plugins and theme translations, but with plugins; one can ask the plugin developer to change one of the strings. With the documentation, the result will be a bad translation.

Versioning

• The docs team wants to introduce documentation for different WordPress versions, this is a good time to start thinking about this as everything needs to be translated.

• For instance, the single article is the Navigation blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience., now the Navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site.. It has changed many times since rolling out the Site Editor. If someone wanted to read the documentation on the Navigation bar at 6.0 because their site uses 6.0, how do we work this out?
• The Learn team can have a similar issue.

• The code reference team uses taxonomies to resolve versioning issues.
• The documentation has the latest version, but now it will add the previous version to the articles. How can this be incorporated into GlotPress?

Multilingual sites

• There are solutions available to work with multilingual sites, and Phase 4 may occur in 3 or 4 years.
• Meanwhile, where do we put the information? How do we move the pieces forward and be ready for when the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. can do it by itself?
• How do we put the URLs back on the website? This has to be resolved before Phase 4
• A solution could be having the articles in GlotPress, which can give that page an original ID. When the page is moved to WordPress, the original ID will move with it, but it will also remain as a master ID in GlotPress.
• The main problem is that we still need to figure out where to store the information before phase 4.
• To avoid wasting developers’ time, start translating what is available now (the most stable is end-user documentation).

Testing GlotPress

• The Spanish team is working on the translation of the first categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of end-user documentation and improving the glossary. That is about 20 articles/pages that can be used to test new GlotPress features.
• Tests can be run from WordPress with the original article.

French community

• The French community has about 90% of the end-user translated. 
• Need to cross-reference the articles to create a table of redirects that will help the meta team when adding the fr.wordpress.org/documentation page. This is the only way to maintain what has already been translated.
• The French translations may need to be updated, as the docs team removed all developer jargon from end-user documentation.
• Any other information added to the articles must be discussed with the docs team before being added to the global English version or removed from the French article.
• The articles must be one-on-one between English and other versions of the language.
• The sitemap has to be translated into French.
• All of these items are part of the meta ticket mentioned at the beginning of this article.

URLs

• Since the URLs are all custom and not content, are they going to be translated?
• The slug is a field in the database.
• URLs should not be arbitrary but should be translated and not changeable.
• Perhaps this should be a role responsibility, and only GTEs or locale managers can set it up.
• What if slugs are not translated? Because there is a decision to be made. What will the correct slug be:
  es.wordpress.org/documentation/ or es.wordpress.org/documentacion/
• This is another task for meta, which already is es.wordpress.org/support/. The full slug is in English.
• Presently, the slugs are in 2 languages:
  https://es.wordpress.org/support/forum/manuales-y-resolucion-de-problemas/
• Using a redirection table that links directly from wordpress.org.
• Perhaps it is better to maintain all the slugs in English as they can maintain the same IDs, which will make it easier to synchronize.
• Also, it would be easier to check on the translation status of a page in another language.
• So if there is a page with a translated slug, we can redirect it only once to the English version (adding the language prefix). If everything is in English, it is easier to maintain.
• In the long term, it is better to keep everything in English because when translations are not available, the site can remain in English.

Props to @courane01, @javiercasares and @nullbyte for reviewing and editing the notes.

#glotpress, #learnwp