Internationalisation of ClassicPress

Io non sono un madre lingua inglese.
I am not a native english speaker.

If you fit in this user case (also for your websites) you will be happy to know that ClassicPress like WordPress is localized in a lot of locales.

Legend:

  • PTE: project translation editor, review permission of strings for plugins/themes *
  • GTE: global translation editor, review permission of strings in all the projects and also in the core *

* In the WP.org Polyglots team of course

The story
When I joined the ClassicPress community I took the leading of i18n team. Basically for my experience as PTE in WordPress, developer of tools for Polyglots like GlotDict that soon will support our instance of GlotPress, part of the GlotPress team (the tool that enable the WP community to localize WP and plugins/themes) I was happy to cover that role.
Usually the other locales (except english) doesn’t receive a lot of love in new projects or forks because there are other stuff to do, like start the forks and replicate the infrastructure.

In the first meeting the founding committee had we chosen to support initially the first set of locales that has more that 2% of usage of WordPress (Stats – WordPress.org check in the bottom). In that way we can test our infrastrucutre and start to build our community.

This taken a bit to replicate GlotPress, create the endpoint for CP and remove all the references from strings to WordPress.

What happened

  • Install and configure GlotPress
  • Define the structure of the projects
  • Create the 11 first locales
  • Create the endpoint that enable CP to download the latest version of the locales
  • Use CP endpoint to download only the core language packs

Everything required a bit because the project was starting so for beta-1 we had no time to do everything but as today we made everything of that list!

Our GP instance is avalaible at https://translate.classicpress.net/ that use the default GP theme (right now we don’t have time to do a new one like WP.org has).
On https://translate.classicpress.net/projects/core/ you can find the list of the first 11 locales that we will support. The next step was cleanup all the strings inside the core that reference wordpress to switch to classicpress.
To simplify that work I chosen to use my language as test so right now only italian is avalaible for that reason. There is the last pull request that remove the last references in that way we can work at localize.
Wait a moment, we don’t need to localize everything from start because right now core is 6000~ strings and for that reason I amde a tiny bash script that download the translation of a locale and replace all the references automatically to simplify that task.
Taking as example the italian this enable us to have to localize only 50~ because are new strings and check only the one with warning that are less of 10.
Before to import also for the other locales availalbe I am waiting the last pull request approved and that our GP instance screen that (we have a cron that run every 8 hours).

Next step was creating the endpoint that is the same of the WP.org to be more compatibile.
So we started studying how to do it Endpoints for translation · Issue #8 · ClassicPress/ClassicPress-APIs · GitHub. We chosen after analyze the code of WP to do a static version instead of use the DB because we need to release and we can improve the infrastructure later.
So starting from class-language-pack.php in sites/trunk/wordpress.org/public_html/wp-content/plugins/wporg-gp-customizations/inc/cli – Making WordPress.org we made a new WP CLI script for GP that works for our needs https://github.com/ClassicPress/ClassicPress-Network/blob/master/wp-content/plugins/cp-gp-cli/inc/class-language-pack.php
This generate a zip file for every locale and the endpoint.

The last step done yesterday was a patch to use our endpoint only for core https://github.com/ClassicPress/ClassicPress/pull/295
So our beta-2 will include that!

What we learned

  • WP.org code is very complicate and without docs, but is a problem of meta but we handle it with testing
  • Work on the infrastructure of a project require skills and a lot of time, also for testing
  • With a team is possible to divide tasks and gather feedback, thanks @james, @pieter and Paolo Falomo
  • A lot of people want this project localized
  • WP CLI is awesome but also GlotPress too

What is yet missing

We have already have few people for vairous locales that want to help us, we are working for you. When everything will be working for beta-2, we will study a plan for the meta side.
The biggest problem is that GP by default doesn’t have PTE/GTE so we have to handle that like WP.org is doing and this will require time but probably with the GP capabilities we will find a way.

How to help

Glad to hear that! As project we need localizers but right now with this very low amount of strings is not so urgent. Instead we need developers that want help us in the Network infrastructure of the project to move on for the polyglots needs but also for the core of course.

For any other questions don’t hesitate to reply!

6 Likes

The technical details of what this script does have changed a bit: now, it only generates the files which absolutely have to be generated using PHP.

Further steps in the process are handled on a separate server, outside of GlotPress: GitHub - ClassyBot/i18n-scripts: Scripts that update and publish ClassicPress translations.

The end result is https://api-v1.classicpress.net/translations/core/1.0.0/translations.json and the translation zip files it links to.

1 Like

Hi. Tried to work with translations but need login credentials to https://translate.classicpress.net/wp-login.php to edit. Also safer for me is to edit files local from .po file if is possible.

Thanks.

1 Like

Hi Dominiq, I written a new post about how to localize How to localize ClassicPress :slight_smile:

3 Likes

@Dominiq editing .po files is probably the way we need to go for now. What do you need in order to start on this?

As long as we have the original .po file and a modified version to compare, we can sort out the changes and get them input into GlotPress.

We’ll also be working on a smoother process for people to contribute translations.

Just .po or .pot files to download, then I can open it in software i’d like, edit, even check raw code in notepad, Afterthat I’m sure all good. Working with glotpress online can’t get that kind of experience.

Just need some structure to download files and then can send it by slack to mod.

Also wrote:

As I written in the other thread, for me using po files is not the best solution at all.
This files doesn’t enable to use the validators and an easy management on a process with over 11 locale with a reviewer for all of them with a bottleneck of someone with permission on the portal.
Anyway we are working now on defining who can review every lanauge we chosen to start right now.
Later we will see the process.

Blockquote
This files doesn’t enable to use the validators and an easy management
Blockquote

Maybe You can check this:

I Have build a little multilanguage blog of itself:
All works perfectly at frontend, made from .po files in 1 day:

http://polylang.you2.pl/

Would You Like to test this Multi Language solution as admin user and share Your experience about Polylang and Editing With Codestyling Localization for check case of validators?

Topic of this project:

Or You can send me directly any problematic phrase or even all install then I can check what’s wrong. System of .po is made perfectly and I know it a more than a little bit , believe can convince You to consider it as fully working which in fact it is.

Merry Christmas!

Polylang is not GlotPress.
It is a plugin that enable the multilanguage in a website but is not for localize projects like GlotPress.
GlotPress has tools to generate po/mo files and his used to localize WP and plugins and is more advanced and focused in what we need.

I know the po files but not works perfectly for a lot of reasons: first of all various tools like PoEdit implement custom headers that are not supported by other tools or the standard so they are not portable. Also require a process with a person to upload in the softweare that elaborate everything if fit in our rules and the various po tools doesn’t support them.
Po files are useful to work as first step as we already done to import a massive number of strings but not to still work with that for our scaling needs.
There is a reason why a lot of OS projects don’t works with them directly but use Transifex, LingoHub, Pontoon and many others to remove the block of a person and improve the validation.

Basically we will use GP only we need time to define:

  • The reviewers for every locale
  • Define what to do for the various issues on permissions with GP

Right now I am working on this 2 points :slight_smile:

1 Like

But Codestyling Locatization is. It is missed from interenet few years ago. Don’t know reasons why.

I have installed working copy at this classicpress installation:

http://polylang.you2.pl/

Also there is .zip file:

http://polylang.you2.pl/codestyling-localization.zip

Unfortunately it is old project, need someone to redevelop it and add direction wp-content/languages/

as for now it reads and creates only languages inside of plugin /language/ catalog.

Rest works as well.

Very good experience of working with for me, looking forward Your opinion.

As it is liteweight it could fit core functionality to handle all .po translations in wp-admin

But after thinking I see theres really to much stairs over there so I leave it lust for the knowledge.

It’s understanding why You using Glotpress as developed working.

Still joined there to add some translations and can’t edit there without login:

n https://translate.classicpress.net/projects/core/

We’re working on logins for the translation system. We’ll make a new post when it’s ready.

3 Likes