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.
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:
| Service | GitHub repository | Link to join | Screenshot |
|---|---|---|---|
| POEditor | GitHub - ClassicPress/i18n-core-poeditor: Testing translations with poeditor.com | Log in - POEditor localization platform | |
| Crowdin | GitHub - ClassicPress/i18n-core-crowdin: Testing translations with classicpress.crowdin.com | Crowdin Enterprise |
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:
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.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.
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:
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).
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: New Crowdin translations by nylen · Pull Request #1 · ClassicPress/i18n-core-crowdin · GitHub 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 
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
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.
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)
#. 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”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
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
(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
@ElisabettaCarrara, please have my vote for it
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.
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?
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.
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?
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
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”.
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: Code Snippet for Custom QA Checks | Crowdin Documentation
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.
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.
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”.
So, it seems we are satisfied with Crowdin.
What’s the next step here?
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)
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):
I am waiting to hear back from the Crowdin team on two related points:
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!
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…