Yes this is mainly what I have been evaluating.
As far as the main part (the translation interface) I am not an expert on these, and Crowdin is not perfect, but I agree it’s the best option we’ve identified so far: it just “does more”.
2 Likes
So, it seems we are satisfied with Crowdin.
What’s the next step here?
2 Likes
I think we need to align locales to the CP current version and decide the process to include translation in sites updates again. It will take time to be ready to do so, but at least having a roadmap will maybe show users we are moving.
Is that something we should discuss in a meeting?
I think that being on two major installers now we are slightly in front of people, so also having a post on the blog showing the roadmap (with clear plans to include languages that for now we do not offer yet, maybe in CP 3) will also be helpful to gather contributors. I think we need people to trust we are going to develop CP and its locales, for it’s clear that locales were slowed down because we needed v1 out and v2 is in the works. I mean, one of the things I check when I select a CMS is if it has the locales I need and if not I ask if they plan to have it at a certain point down the road. I think answerring this in a roadmap is better than not saying where we are headed with this. (People will ask at a certain point. WP has a gazillion of locales, even minority ones. And users love to stuck fingers in the cut sometimes, just because they can)
1 Like
I think a meeting would be a good idea. I think these are the next immediate steps before we can start serving translations again (not necessarily in strict order):
- Approve the existing translations that do not have QA check errors. Some of the QA checks point to valid issues, but not all of them.
- Create and test a workflow for upgrading our translations (currently the strings and translations are on ClassicPress v1.0.0 so that we can test this).
- Get to 0 QA errors by a combination of fixing our existing translations and improving the QA checks.
- Integrate our GitHub repository with a process to update the translations API (this one probably does need to come after the other steps).
I am waiting to hear back from the Crowdin team on two related points:
- How to filter translations to only those which do not have any QA errors (doesn’t appear to be possible at the moment, but should be easy for them to fix)
- Whether they can provide the logic for their existing “Special characters” QA check as code that we can modify to our needs (would save some time)
3 Likes
Ok. I will summarize this tomorrow in an agenda and post a doodle to confirm people’s availability.
I think we can try to schedule for next week.
Thanks!
2 Likes
This probably isn’t going to be feasible since the QA checks are not very customizable unless we rewrite them ourselves.
The first of these is in their development queue, but we need to move forward with this anyway.
The second (sharing their existing QA check logic) is not something they’ll be able to do.
Next steps here:
Great share to know…
3 Likes