POEditor vs. GlotPress

Thanks @james!

I really think you are right in saying using an official repo is the way to go.

I think crowdin seems promising also for the 2fa that POEditor does not have. I know you explained it’s not needed so much, but them offering it it’s something that makes me think they are actively developing the platform.

1 Like

Ok, we have both services set up now, with the strings from ClassicPress 1.0.0 (old version, this way we can update the strings and use that as a test). Each one is linked to a GitHub repository.

@ElisabettaCarrara I’ve sent you an invite to manage both projects, and here are links that anyone else should be able to use to join also:

Crowdin is fully functional, POEditor is up and running but we’ve hit the string limit for their free trial and they still haven’t responded to my request to recognize us as an open-source project.

Thoughts so far:

  • Crowdin seems much more polished and full-featured overall
  • GitHub integration with POEditor is manual (have to import/export translations using a button)
  • GitHub integration with Crowdin is fully automatic. New translations are automatically pushed to a branch and a PR for review. Still need to test what happens when we get new source translations (and multiple versions), and I don’t see a button to “refresh everything” related to the integration, but so far this is pretty nice
  • Crowdin doesn’t know how to handle lots of strings like What’s New - it expects the ’ “fancy apostrophe” to appear in the translated string even though in most languages it won’t. There are a lot of validation errors with our existing translations as a result of issues like this.
  • The string editing interface for Crowdin seems full-featured (helps you match HTML tags, etc) but maybe a bit clunky.
  • The string editing interface for POEditor is much simpler but seems very clear and nice to use.
  • It’s very easy to get in touch with a human at Crowdin, not so much at POEditor.

Summary - so far it looks like Crowdin will be a better fit, but neither of these solutions will be as seamless as GlotPress if we can host and maintain it well.

5 Likes

Received the invitations, thanks @james! will look around and start to get comfortable with them to try and test.

I agree that working on GlotPress may offer us a very streamlined solution completely tailored to our needs, but this requires basically:

  • more people able to manage it and set it up in a way it is secure
  • time

We may have time, at least we may show people a roadmap for it and show that at our pace the thing is progressing, but for this to work we need devs. And even if we have devs and time, I think security first matters. (I think the current devs have a lot on their plates, so better think that if we need GlotPress we have to launch a campaign to increase the number of people willing to roll sleeves up, before even starting to discuss about setting it up and testing it)

Crowdin vs. POEditor, I’ll say what I think after testing them.

Crowdin

spent five minutes in crowdin since my hands were itching.

Nothing to say on the Translation workflow, revisors here are called Proofeditors.

The encoding issue about characters is present also in the present version of translatewordpress (both.com and .org) so I do not see it as an issue since we need the strings be approved by revisors before releasing and if they are flagged as approved the system won’t bother.

The workflow is very similar (much more than translatewordpress) to a CAT tool, this makes for easy contriubution even from people who are “just translators” willing to srtart collaboration with the open source world. (if you need proof of this, just visit matecat and see the imterface, it’s just one of the most used web based, stored in cloud CAT tools but there are many and the interface is very similar and every translator is familiar with this).

That said we need to understand how it handles the workflow and how it reacts when various people are editing various locales at the same time and in big numbers.

One thing we need testing on is when new string get added to the locale, and what happens when the locales get updated and pushed to the repo. Is the merge to the repo done automathically? this I would not like… I would prefer that at repo’s level and admin action takes place to definitely merge to the core and serve updated translations.

I tried to send some strings and on the translation screen it is not marking them as pending review, since I act in that role as a translator. Have to verify if Proofreaders can filter the “to be proofreaded” strings only to work on them.

Bonus points, connects to Jira and Zendesk.

I have couple ideas about using those in the very future but it’s another branch entirely.

Overall I think this is what we need, and if we think that third party is the way to go, for now Crowdin has my vote (untill I test POEditor).

3 Likes

GlotPress does not have the issue where encoded characters are expected to be in the resulting translation, and this is marked as a validation error if they’re not. This has the potential to be a fairly big wart on our processes IMO.


Answered above, though perhaps not very clearly:

You can see an example here: https://github.com/ClassicPress/i18n-core-crowdin/pull/1 Crowdin has created this pull request automatically, and it is awaiting review and merge by an administrator.

However this is mostly a non-issue: if the platform we choose doesn’t have a workflow like this, then we can easily create it.


Zendesk, ok, sure. Let’s not ever do Jira please :slight_smile:


I think we are going to need to set up a trial of GlotPress again also. We do know how to do this properly and I think there are a lot of long-term benefits. Let’s see how long it takes once I actually start on it. In the meantime there is plenty for you and others to play with :slight_smile:

1 Like

We do use jira in Tumblr tickets but I have not really encountered it in all its Glory.

As x glotpress, I am playing with it also, in a secret cave.

Let’s see how much it takes me to understand the gist of it.

1 Like

I’ve played with Crowding for a while and read its documentation. First impression is quite positive. This is probably the most professional and elaborate environment I’ve ever used for localization. Not perfect, for sure, but powerful.

Flaws (for now)

  • QA Checks fail on special characters (mentioned by James above)
  • Editor (for some reasons) doesn’t show extracted comments in Context section (strings starting with #. extracted from // translators: ... comments in code). This is often needed, since those comments usually explain the meaning of the variables like here “%1$s ‹ %2$s — ClassicPress
  • No source linking (can’t click to view the string in a source file in native context)

However, I haven’t seen admin settings page. Maybe those things are customizable or have some workarounds.

For example, I see QA Check Parameters in docs. Maybe playing with ‘Special characters mismatch’ rule (= special_symbols param in API request for create-project) will give us a solution. Or maybe we should just review our source files and use some other method to insert/escape such characters. (I don’t think we are the first people facing this behavior. And since it’s not yet fixed in Crowdin, maybe there is another way/method to deal with them. We can ask support after all).

Experiensed benefits

  • Merging files is quick and nice (uploaded localized core 1.1.0 adding ~200 strings - ok)
  • Great UI in Editor (fast, solid, clean, flexible, has light/dark themes, no annoying buggers)
  • Great suggestion/memory system, really helpful.

Theoretical benefits and nice features from documentation

  • Versions management
    Supports branches and suggests workflow to manage versions. Workflow (sequence of processes) is customizable.

  • Custom Domain
    “This option allows you to publish your Crowdin project on your own domain name”.
    We can still use translate.classicpress.net and nominally stay within the project ‘home’, which is cool.

  • Single Sign-On (SSO)
    “You can use the Single Sign-On (SSO) feature to authenticate instantly your users with their existing usernames.” (So it meets 2FA and SSO both expectations noted by security team, @invisnet).

  • Notifications
    Can notify translators about new strings, project managers about new strings, project managers about language translation/validation completion.
    This simple thing is probably the worst bottleneck of the translate.wordpress.org service. PTE doesn’t get notifications about new strings added/translated. As a result strings often remain unapproved for years (literally) and never get into production, which is awful. Glotpress has no notification system by default. So this small thing can influence a lot.

  • Assets Localization
    Can store and reference localized versions of mediafiles (e.g. psd, svg logos, fonts etc).

  • Can attach screenshots
    Managers can attach screenshots to provide additional context for translators. Might be quite helpful sometimes. E.g. when localizing complicated GUI elements: forms, filters. Translators also have a link to request context for a string.

  • Pseudo-localization
    This seems to be a nice thing to test sustainability of new interfaces. Variable strings length, character sets and other.

Personal considerations

  • Yandex.Translate engine option in some screenshots makes me happy.
  • Figma plugin to localize UI artboatrs makes me happy, too.

(I don’t mean to use these options for CP, but consider this as a very good sign. It shows that Crowdin is up to date and is designed for people using similar tools/stack/workflow).

Intermediate conclusion:
— Crowdin is much more powerful than Poeditor
— Crowdin is much more powerful than (default) GlotPress and can be raised much faster with less effort.

I’m leaning towards choosing Crowdin at least until we run into some critical unrecoverable problem. In the latter case, we can always move back to GlotPress and slowly develop it into a similar system until it becomes Crowdin :slight_smile:

@ElisabettaCarrara, please have my vote for it :slight_smile:

P.S. @james, I’ve send you a message in Crowdin) Could you please give me temporary access to the admin interface? (If of course this is allowed). I’m very curious to see all settings available for Enterprise project and to estimate their UI solutions.

3 Likes

I noticed this also. I think it has the potential to be pretty deeply annoying, but what do others think?

No problem here, @ElisabettaCarrara if you agree can you do this please?

2 Likes

A post was split to a new topic: Automatic translation updates using GlotPress + “traduttore” plugin

@norske: I increased your access in the Crowdin dashboard. Please feel free to take a look around.

I appreciate the test, but I think you shouldn’t be able to add new strings! We will probably need to manage this based on the branches from the source repository, and I guess we need to be able to keep different “sets” of translations for each version according to Crowdin branches. I started this test with the strings from ClassicPress 1.0.0 to see how the process of preparing for new versions can work.

I have also written to Crowdin about the few things we seem to be missing so far.

Finally, POEditor has granted our request to be recognized as an open source project (remove string limits, etc) and they have also fixed an issue I reported with their site.

I do think we should still finish out our testing with POEditor (and GlotPress, if time permits). At the very least, I hope Crowdin will be able to fix a few of these issues - missing translator comments in particular will hurt translation quality.

2 Likes

I took another look at the project in Crowdin and I guess I didn’t understand this correctly the first time I read it. It looks like this added new translations, not new source strings (which is what we would want to happen). Did Crowdin tell you how many strings in your .po file were matched vs not matched against our project? I don’t suppose you have a screenshot handy of what happened when you imported a file?

1 Like

Yes, that’s right. My bad, probably. I should say ‘translated’, not ‘localized’)

To be honest, I didn’t notice that. But… I see the “Undo” button in activity list, so I think we can use time machine and find this out :slight_smile:

I’ve created another user to test things clearly with no manager permissions. And here we go. Now we have 40 045 translated words and 43 297 total (92%). And 0 strings approved for now.

When uploading a .po file to merge, I have an option to mark new strings as done (which is ok). But I also have an option to mark them as approved (which to my mind is weird for a non-manager user so I won’t check this option this time).

Result: 42 467 words translated and still 43 297 total (98%). So, yes, it adds translations and not the source strings, which is fine. (Small update: just ensured that my uploaded file actually contains additional strings from 1.1.0 related to Security page and those strings were ignored as expected).

And a surprise. There is a full list of comments in the Context section now! If you didn’t modify the source pot, it looks like they fixed that issue (?).

Update: by default it counts the words (not strings). I missed that, all reported numbers in previous messages should be “words”.

3 Likes

Yep, their support team told me how to fix this. In our .pot file we had something like this:

#. this is a translator comment

#: this is where the string appears
msgid "the string"

After removing the blank line in between the two types of comments as they recommended, all context started showing up correctly (without me having to do anything else - their GitHub integration really works!)

They weren’t able to help as much with the QA check issues, but in theory we could replace their “Special characters and entities” QA check with some custom code that works more like what we need: https://support.crowdin.com/enterprise/code-snippet-qa-checks/

IMO let’s not worry about this - I think it worked correctly, Russian is almost fully translated now and I just got confused before.

Yes, I think only managers should be able to “approve” strings. There is a whole “Workflow” section where we can customize the proofreading steps (or even remove it entirely and handle verification separately, once the strings get to GitHub).

I asked the support team for another related enhancement - I couldn’t figure out how to select only the unapproved strings that do not have any QA errors, since these errors do point to real issues in a lot of cases.

I also played with POEditor a bit more. By comparison it is very basic, they have a GitHub integration but it is not automatic. They also recommend making a new project for each version of the software that needs to be translated, which would work but it’s definitely not ideal.

1 Like

And as a translator I am very happy that from this discussion the best tool was identified.
As a translator accustomed to cat tools I can understand them at first glance.
But to localize CP the tool must be friendly for coders and work with our software/ecosystem.
That is why I needed other people to test a third party option. I have used too many cats in my life and this I not one person’s decision. It needs to be a team effort.

3 Likes

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