I18n January-March 2020 Quarterly report

I took the lead of the i18n team in January, so I am going to report what has been done from January on.

What we did as a team, in short, was acknowledging the role of localization in the ClassicPress environment and setting a path to be able to offer localization in a timely and organic manner, opening the process up to contributors while we develop the processes.

This brought us to discuss the tools/infrastructures that were needed to perform at best, we discussed the opportunity to set up a complete GlotPress install vs. going the third-party tools/infrastructures route.

I won’t go into much detail here, we decided that to offer the best service to the community in the shortest time possible we needed to select a third-party tool.

We debated which one was the best for our needs, and the decision fell on Crowdin.

What we did after was setting Crowdin up for testing with the materials that were left from the previous i18n team operation.

After testing we are pretty satisfied with the workflow and we are ready to really dive in the hard work, the next steps we envision are:

  1. approving the locales we already have available in Crowdin following the process @james outlined here (this is something we will do at a team lead level)
  2. setting up Glossary and Style Guide (this I am personally taking care of and is needed to allow us a smooth translation workflow, will update everybody once it’s ready)
  3. including en_GB locale that we will set as default both for new installations and as a source for all the other locales - thanks for @1stepforward for his involvement in this.
  4. opening up the project for contribution with the cooperation of the community. We are going to set reviewers for each locale
  5. the reviewers at this stage will help align the locales to ClassicPress current version
  6. this will allow us to build the first translation release for year 2020

I think steps 1 to 5 belong to the next quarter (April-June 2020) and that step 6 may happen any time during the third quarter.

As concerns 4, this thread serves as a call to action. If you want to be involved in a locale, just state that in the comments, and once reached stage 4 you will be included in the locale you have volunteered for.

All this arises some thoughts I want to share with you all in terms of what I feel the i18n team role is in ClassicPress future spreading and growth.

I think offering locales to the community, and allowing the community to give back to the project in the form of volunteered translations can help ClassicPress to build and develop healthy bonds with the broader community, also considering that we have been included in two major one-click installers.

This may lead us to think we need to outsmart WordPress by immediately adding a long list of locales “because people want them all”, but I think every addition has to be vetted with a specific criterion in mind, that is how many people are able to contribute to it in a stable and consistent way. Are these people enough to ensure quality service to the community for this locale?

Please note: in my opinion, we should not measure the value a locale brings to ClassicPress only by judging from the number of users asking for it. This may lead us to leave entire communities behind.

Another thing I have spent time reflecting on is the way translation releases should be organized, and on this, I did not come up with a clear opinion yet, so I will just spell the options I see and let this open for further discussion.

Should we establish a workflow allowing us to release translations at certain fixed deadlines (every quarter, every month, every semester… you get it) or should we just roll out a monthly release with what we have from time to time when we start rolling out translations?

Any ideas, questions, remarks, proposals… just publish a linked post.

This is it, for now, thanks for supporting i18n team in this endeavor!

7 Likes

Just to confirm my position on 3).

I think the default should be left as en_US and that en_US still be used as the basis for all other locales. I’d just like en_GB to be included as an option during installation and I’m happy to help in any way I can with that.

7 Likes

+1 for default en_US. Because of many reasons, not because I don’t like GB.

3 Likes

Thanks for helping us get ClassicPress translations moving again.

“this is something we will do at a team lead level” - who specifically will be taking this on?

It makes sense to me to add en_GB and use that to draft a process for adding new locales, but not to set en_GB as the new default locale. There would be two ways to do this, both with significant drawbacks - changing all the strings in core (lots of work), or forcing all installations to download the en_GB translations and use them by default (hacky, extra files and network requests).

We had a call for volunteers 3 months ago (December 2019): Call for volunteers to translate ClassicPress Contacting the people who expressed interest there would be a good next step.

Definitely agree with this. We also have several languages that may not meet these criteria at the moment (e.g. Turkish, Japanese, two variants of Portuguese) and we need to decide what to do with these also.

This is worthy of a separate topic but I don’t think we know the answer yet.

2 Likes

Me? I guess I am i18n team lead… :rofl: - was just trying to avoid repeating same sentence over so I got creative.

Agreed on using en_US as default, and adding en_GB as an option.

As concerns call to action, I will update the section and get in touch.

About “what to do with some of the locales” and “how to manage releases” we need to discuss. Do you think opening threads in forum is enough?

1 Like

Sounds fine to me :+1:

1 Like