POEditor vs. GlotPress

After the i18n meeting we had on January I have been thinking of the proposal highlighted here.

As you can see it’s a big change, backed up with good reasons.

Some points have been raised in i18n on Slack, where I also published it.

@norske pointed out we need to make sure if this solution allows for seamless deployment of translated files to CP sites, while @james pointed out that what we did before while using GlotPress was a manual deployment, so all in all, even if we opt for GlotPress, there are some adjustments needed to make it work as intended.

This for reference on deployment.

Norske suggested also we evaluate other platforms to localize CP, like Virtaal.

Also, we noted that we need the involvement of the Infrastructure team in order to understand better the technical side of things.

Another point I can rise is that at least GlotPress is a well-known solution, even if there are better solutions out there. But to be clear, I am strongly advocating for a solution different from GlotPress.

Other third party tools to also review and discuss:

So I am inviting the community on this post to discuss the matter.

tagging for reference @james, @invisnet, @norske

6 Likes

Is this something for which ClassicPress wants or is willing to pay? If so, what sort of sums are you willing to spend? The third party tools you listed all have a monthly cost to them.

Virtaal is an offline translation tool so would raise the bar for people doing the localization over GlotPress in that you’d need them to download and install some software as well as download and upload the files.

1 Like

Some of those are listed here, along with a few others: Best translation software of 2023 | TechRadar

1 Like

Just a quick reply to clarify the subject:

Those tools (at least lingohub, transifex and crowdin) offer free plans for open source projects. So, we are discussing only tools which are available for free.

Please notice that this list is just a set of random examples. I’ve mentioned them in Slack to illustrate that there are different alternatives and methods of managing localization and we can analyse them before making any decision about poeditor/glotpress.

Please read “Virtaal” as “Pootle”. These are the parts of the same set of tools Products | Translate House
and I just mentioned the wrong title in Slack since they are the same “brand”/solution for me. This set has a server-side solution, which works the same way as GlotPress does.

2 Likes

Free for open source projects is a good and reasonable requirement for us. POEditor (poeditor.com) meets this requirement. Their API and GitHub support should let us do what we need regarding verifying, updating and serving translations on our end, and they offer unlimited strings for open-source projects.

We’ve already looked at most of these other hosted options and I think we can pretty quickly rule out all of them except poeditor.com.

LingoHub is free for open source projects but will limit us to 10 active users, and I think we’ll grow beyond that pretty quickly. I’d rather not have to do all of this again in a year.

Transifex is free for open source projects with no revenue which would be a problem since we accept donations. Also not a good limitation to accept for the long term.

OneSky appears to be more of a paid translation service that also has a platform built in, rather than a community translation platform. I do not see an option for open-source projects on their website (which is generally rather slow and clunky).

Crowdin has pretty strict limits on number of strings, and they don’t say which plan a free open-source license would fall under. They also write this which doesn’t sound amazing to me: “Note: As an Open Source project maintainer by submitting the form you agree to: join Crowdin beta group and try Crowdin’s latest features, contribute your project translations to Crowdin Global TM and gain access to Crowdin Neural Machine Translator. The requirements do not apply to paid customers.”

4 Likes

Okay, apologies, I’d missed the “free for open source” pieces when I looked at them.

5 Likes

All what @james said was the reason I did not mention all the above in my doc.
It’s not to avoid discussing these, but to have a short doc pointing out my proposal that is using POEditor.

To make a decision we need to be sure we want to stick with what we select, since we will have to stick to it in the long run and also defend our choice.

2 Likes

To respond to the question at the end of the proposal document:

Do we stay with GlotPress, or do we open a new path with POEditor for ClassicPress?

I’m fine with either of these options, but it’s certainly true that going with POEditor.com will mean significantly less work in terms of our hosting and other infrastructure. So I support this proposal.

8 Likes

So…

Please note that my attitude to GlotPress/Poeditor is absolutely neutral. I’ve suggested using Poeditor almost a year ago, too. That time it was just a momentary idea with no proof of concept, but I’ve played this service for a couple of hours and I like it in general. I also like changes and usually don’t resist new ideas :slight_smile:

During the last i18n meeting I’ve promised to play around GlotPress in February to define its backend possibilities. We didn’t consider moving to third party service that time and (as you fairly noted in your doc) this is rather big change, which requires some research. Being a practician I can’t give any thoughtful opinion before I ‘touch’ both tools with my own hands (or get the same information from others). I don’t mean a quick look from a user side, but setting the environment - server/API/account, sample data, sample users. Daily usage usually makes completely different impression than surface look.

Since this topic is a bit unexpected and speeds up things, I still don’t have any complete opinion about GlotPress (and Poeditor is still kinda terra incognita :). However, I’ve spend last night playing GlotPress and that gave me some more things to think about.

First of all, I completely agree with @james that “less work in terms of our hosting and other infrastructure” is a very strong arguement. This might be critical in our case.

On the other hand, this also means that our workflow will strongly depend on external service design and functionality (UI + API). This solution is theoretically cheap, but not very flexible. (And has some hypothetical risks which is obvious, so I won’t focus on it)

To my mind, the most important advantage of GlotPress is that it is completely customizable. I mean literally. I see that it has a simple and nice template system and a wide bunch of hooks. We can

  • change design/styling (pretty simple),
  • change page layouts (pretty simple),
  • add markup and custom functionality,
  • adjust users permissions (theoretically),
  • implement universal authorization across CP websites,
  • build our own worklow and improve it when needed,
  • combine it with other plugins or bridges (like WP.org does) to gather stats.

Certainly, we are not going to do all this right now at a time. But at least this is possible. Using third party service is competely another strategy.

And here are some screenshots. I think it’s important to see the ‘administrative’ part of the interface. When we are talking about GlotPress, many of us imagine translate.wordpress.org (its front end side) and think this is a dogma. But as far as I see, it’s just one way of using GlotPress.

For example, we can use version control and follow the structure of github repository

We can link any project to any source file in the repository (like trac links in WP)

We can copy translations from the previous branch in a couple of clicks

We can customize it in any way
(Just playing. I’ve tested styling by copying glotpress tempates into a site custom theme and using functions.php to enqueue additional style and aplly title filter. It took 5 min, BTW).

image

We can manage locales (and we know it’s ok)

(I haven’t yet tested user permissions. Defaults are: any registered user can suggest a translation, validators can approve strings for certain projects, admins can set validators. Pretty simple).

P.S. Unfortunately, I have no time to test Poeditor now. I’ve created an account with a sample project and github connection, but we need to put po files directly there to test import and other things (speed when processing files with 2-3k strings and other things). It would be nice if someone does it. However, trial has limit of 1000 strings which is not enough to make any trustful conclusion.

Hope this helps.

5 Likes

Yes @norske, this helps.
It’s the kind of discussion I wanted to start.
Now, I have couple free days. And I was thinking at least to understand the core differences among the two.

Fact is GlotPress may be very customizable, and something everybody knows for basically it’s WP but security has to go first.

  • lives on our infrastructure. A chain is strong like it’s weaker link.

That is why I started this debate.

I think we can adapt to a bit less features and rely on a third party service, but it’s clear we need testing before a decision can be made.

What if as Translation team lead I set up a POEditor install for open source projects (free) for us to play with to understand it?

1 Like

I’m not in a position to evaluate whether POEditor is a suitable i18n tool (not my area), so let’s assume it is.

On the security side it’s missing a couple of things I would have liked to see: support for 2FA and SSO (or at least I can see no evidence of either).

Neither is a deal-breaker, but if there were something functionally identical to POEditor with either that’d be the better choice. However, I’m not sure there’s another choice, so if we’re serious about using them I’ll drop them an email and see what they have to say.

3 Likes

Thanks for this insight about security.

2fa is indeed not a “nice-to-have”, it’s a requirement.

I am investigating about both solutions by digging in documentation so maybe there is some sort of answer there about this.

What I think is with either of the two there is a compromise, since the perfect solution has not being invented yet.

EDITED TO ADD: apparently someone asked for it. But the feature request has just one vote.

EDITED 2: I tried signing in. And they do not have SSO nor 2fa.

This changes my perspective slightly.

They have a wp plugin used to source translations and manage them, and an API system. Could those be used to work around the lack of SSO and 2fa?

EDITED 3: their plugin is for themes/plugin localization. Not for core.

For core it can connect to GitHub and manage files - scary without a 2fa feature.

GlotPress may not be the securest of the platforms, but it’s true that having time we can find a way to improve it. With POEditor we have to take it as is.

I think I opened a very big can of worms…

Now it has 4 - for some reason I could cast 3 votes - don’t ask me, I’ve no idea.

3 Likes
  1. Seems apparently a way they are using to check how much one “likes” the idea

1, I vote for it but not essential
2, I am interested, it’s a nice to have
3, OMG! I want this so much

But, it’s so strange as a logic.

They not only weight how many voted, but how much they like it.

Since I am never happy, I just evaluated crowdin.

It has 2fa. It has many other nice to have in terms of translation management workflow.

Free for open source projects.

I am digging deeper to see if it could be a good fit for us.

This is a good starting point.

If I understand it right, this doesn’t impose any obligations on us (we can still refuse using it), and it is absolutely right to start with a staging before making any further steps. Here are some things that we might want to test:

  • emulate draft projects structure (we probably need subprojects for minor releases and branches);
  • connect Github account;
  • add 3-5 users, set permissions (submit, validate, admin or anything else if exist), define the procedure for new volunteers to join the project(s);
  • import translation sets at least for 2 locales with at least 2000 strings (some services are slow/unstable when managing huge pieces/sets of data and WP i18n is rather branched);
  • “translate” (submit) at least 100 stings at one session to find possible issues of the solid workflow (annoying UI, slow scripts, spellcheck issues, typical mess sources) and service benefits (syntax highlight, translation suggestions, internal re-use etc);
  • approve some strings to test validators workflow and notification system;
  • export a couple of sets and think about possibilities of automatization (read API docs).

I think these actions will reveal most of the bottlenecks (except security) and refresh the list of pors/contras, add some more specific positions to compare.

We should keep in mind that we need a system to manage not a single product (theme or plugin), but a “factory” of products. This means that typical end-user solutions and tools may not fit our goals (like poeditor’s wp plugin).

GlotPress just uses wp_users db table and native WP registration/authorization system. So, it completely depends on WP install settings. I think there are plugins adding 2fa. (However, I can’t estimate their security level).

2fa should not be a requirement for [non-critical] infrastructure that we are not hosting ourselves. Edit: by “non-critical” infrastructure, I mean that someone will not be able to damage ClassicPress just by entering an incorrect or malicious translation.

We’ll have to verify the safety of what is coming out of any translation system that we use, there’s no way around that. We can put all of our translated strings into a GitHub repository, which will allow us to inspect and verify any changes before deploying them, and will also have other benefits like backups and rollbacks.

I think setting up a trial run is a very good idea, especially if we are now considering other options than POEditor.com and GlotPress.

We’ve already effectively done a trial of GlotPress since we had it running for a while in late 2018 - early 2019. I would summarize the results as follows: it’s theoretically possible to make it do anything we want, but in practice this requires careful testing (which takes a lot of time), and it’s very hard to host GlotPress in a way that is up to our security standards.

1 Like

Writing from mobile, forgive mistakes and poor English.

First. POEditor and Crowdin are very similar (equals). Crowdin has 2fa. Both allow free usage for open source projects.

Second, I may agree with @james about 2fa, but deciding between two equals where one has it and the other doesn’t, for me security first.

Third, going to get in touch with both tomorrow and setup tests.

I agree we need to identify bottlenecks and getting the hands inside is the best way to do that.

POEditor also has a nice plugin to localize plugin & themes, so if we select that, we may be one step ahead for when time for this comes.

I also investigated on out of the box solutions like bridging tools like matecat cat tool with CP. But this is not a viable option, even if maybe it’s doable.

We need to know how many strings Crowdin will give us as an open source project, they don’t say this on their site but POEditor is unlimited. There’s also this:

2fa for non-critical infrastructure that we don’t host ourselves is a pretty minor concern. We should be making this decision on the basis of features instead.

POEditor has enough on their site to convince me that it will be able to do everything we need from a technical standpoint. Crowdin generally doesn’t and I have a couple of concerns as noted above.

A full test will undoubtedly reveal more. I expect that process could take several months from start to finish.

1 Like

I know this whole process is going to take time. Important thing I we do not stall on deciding to use something “because this is what others use”. We need to be really sure. And at least test two options like crowdin and POEditor to make a real and informed decision.

As I said before, all platforms have different prod and cons. And as you and @norske notes, a well performed test is what we need now.

I want to make one thing clear. I don’t want to rush things. I want to have sustainable goals and take each step in a serious way… But we all know that this is very far behind, I know it’s behind for very good reasons, but we need to build momentum now. This will reflect on our brand credibility in front of users.

So I am going to be very annoying. I will roll my sleeves and get this thing moving. In a year I want at least to get this started on a good path.

It will take more than a year to get ALL the translation/localization going, and starting the right way is key to success.

4 Likes