Hey,
while preparing the next release I bumped into crowdin. After fiddling a little bit around I’ve got it working again and the workflow seems to be okay. But the question raised if we need crowdin for translations anymore or if accepting translation PR’s on github would be good enough?
wvengen
In the past, when non-technical people were translating (also in complete new languages), a tool like crowdin helped a lot (especially with the in-context translation for live previews - unfortunately the translation instance has been disabled for a while because of performance issues on the server). Nowadays, I think most i18n contributions are by technical people, so perhaps we could reduce the complexity and just accept PRs for text translations (we’ve had one or two i18n PRs that I referred to Crowdin).
But once you’ve figured out how it works (and you’re happy enough with it), we can also keep using it.
To rekindle an old discussion: on remarks made by @wvengen I have added translation corrections/additions to CrowdIn.
This was based on omissions I encountered in the nl.yml file compared to the en.yml one for which I created a PR.
I did, however, notice that a few more keys were missing which I hadn’t noticed before but those were shown in CrowdIn. So from that respect I suspect CrowdIn is the safer option?
From a developers PoV I am used to have a script (in a project I work on) that runs when code is unit tested which returns the missing language keys so they can immediately be added. But that is not an OSS product
I did notice another (minor) thing: I can’t add corrections to the en.yml (for simple typos) apparently.
Either way: for clarity it would be useful to know what the preferred workflow actually is.
Also ping to @steffen and @yksflip (not sure whether this is redundant on this platform)
and