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
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).
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.