Hm. I saw that particular PR, but didn’t understand at all what it’s all about. Especially what it has to do with Weblate?
The only valid thing I can see in there, is that reaching “The Syncthing Maintainters” is pretty hard except for the security@ e-mail address. Everything else seems to require signing up either here on the forum or on GitHub. Which is okay if we want to avoid being spammed. But I noticed many other projects do provide a translations mailing list to get in contact without registration. Should we install a translations _AT_ syncthing.net alias?
I’m fine with it given the two requirements I had noted, 1) that it produces the JSON files we need in a reasonable manner () and 2) that it not be worse than Transifex about requiring manual busywork to maintain users and permissions ().
Having to register on the forum or send someone an email to receive an invitation seems like a step backwards from the status quo on the second point.
A third point could be that the cost of moving, in terms of pain, should be lower than the gains after moving. Here I’m primarily thinking of us essentially booting all our existing translators and requiring them to move to and learn a new system, which is not something I can quantify really, but it’s not positive at least so there needs to be good stuff as a counterweight.
Only that it came from a Weblate contributor, seems to regularly happen to projects who sign up for Weblate (I looked at their PR history), and mentions Weblate as a reference. In my mind it reflects on Weblate, but no; as mentioned it has roughly zero bearing on the whole question about whether to move there.
Well if I understand correctly there is a “Public” mode for a project where basically anyone can contribute without prior approval. But that gives us the risk of vandalism. Users can be explicitly blocked from a project though if that should happen.
Regarding migration effort vs. improvement, I did volunteer to handle the signup process and user management if necessary, right? On Transifex I don’t have access to do it, but I think it should be shared among several shoulders anyway. Just waiting for the ususal suspects here to give me their user names and get added as admins as well.
We don’t have to abandon Transifex completely by the way. Weblate handles external modifications to the translation files very easily. If we find a way to make Transifex accept them as well, we could in theory stay open to both solutions.
Sorry gotta go now, I’ll get back to the topic tonight or tomorrow.
Short update regarding the Weblate Libre plan, this came in today from their support team:
Hello André,
I can understand that you are moving forward through a large process. Syncthing is a great project; we know it will stay active and grow. Just consider posting an announcement to inform the translators in the time before the setup is finished.
So welcome to the community! We approved your request, and you can now use Weblate and all its features!
Once you mention Weblate in the README and the website of your project, you can use the lovely content from the Share menu of your Weblate project for this presentation.
Last thing for now: The free hosting still costs us some money. If you’re in a position to do that, you are welcome to support Weblate in providing this service to libre projects gratis: https://weblate.org/donate/. And you can follow us on Mastodon, too! Weblate (@weblate@fosstodon.org) - Fosstodon.
Kind regards,
Benjamin
–
Weblate
Now I’ll try to get them to switch it to “Public” mode instead of “Protected”, which should basically cover what @calmh requested regarding liberal access management:
Well from Weblate’s point that seems to be no problem. But I don’t even know how Transifex gets its updated strings or whether changed translations will get picked up. If the two platforms end up in a constant fight over which translations are the latest, that won’t work in parallel. But I’d need more insight into how Transifex interfaces with our repo to find a solution.
I don’t really see a good way of having both active at the same time. Presuming that both can pick up changes from the repo, how would we do the import without one overwriting the other? We’d need to somehow do change detection per phrase, something much more complicated than we do now. (For example, just importing first Transifex and then Weblate would lose changes made in Transifex.) For it to work properly there’d have to be some sort of more real-time update directly between Transifex and Weblate, without going via our repo.
Weblate uses Git internally, and does a rebase of its changes when the upstream repo has new commits. As long as that doesn’t cause conflicts, things will work fine for picking up Transifex changes in Weblate. Since we are pulling the changes from both sides via scripts, I guess we have full control over how it gets merged, but on the Transifex side we’d have to implement some more complicated Git magic ourselves.
Real conflicts (strings edited on both platforms) will always cause trouble.
Overall I think for a transition period of a couple weeks / months I can handle merging the remaining changes from Transifex regularly with manual involvement. The big question is how would Transifex pick up the resolution? Should we upload translated JSON files through their API? I think they do support a download - translate - upload workflow.
Transifex can pull translations from our repo, but I don’t see that this helps. We do periodic sync from our translation service(s) to the repo. If, during that time, someone changed phrase A in Transifex and phrase B in Weblate, how do we import both? Sure, we’re using scripts on our side so we have the power to implement what we want, but we’d have to do just that – load the local json, the transifex json, the weblate json, and do some sort of three-way merge. Perhaps as simple as picking whatever translation is different from our local repo? But we’d need to do it per phrase per language, instead of treating a language as a single atomic blob like it’s now. It’s a fair amount of moving parts and scripting.
(I don’t think anyone suggested it, but just so that we’re clear: I don’t want lots of automatic commits on our repo tracking translations as they happen in realtime. Perhaps if translations were tracked in a separate repo somewhere, that could be an option.)
Yeah we’re clear on the infrequent commits. If it helps, we could make pushes to a separate branch, or have PRs created automatically with manual, opportunistic merging. But the current script solution is perfectly fine, especially since it also covers authors and stuff.
The merge will happen on Weblate’s side automatically. It creates commits for changed strings in its internal repo. When being notified of new upstream commits via Webhooks, these are pulled and then outstanding changes (not yet pulled in via script) rebased on top of the latest state. That’s where merging on a string-level basis happens.
When downloading via script, we’d basically have to make sure the latest state of things has been imported to the translation service first, and whatever we will download already includes the merged changes from the other side. Using Webhooks on both sides and leaving some reasonable time interval between the two scripts should make that work. That would be the minimum of moving parts, but of course still fragile and prone to need manual intervention.
In the end, I guess it would end up being a committee decision to switch and retire Transifex at some point, not keep both platforms. The committee being the people who volunteer to handle the involved work. I do see great benefits in Weblate over Transifex, hopefully we can reach a rough consensus on that point before going out of our way to make both work in parallel.
One more advantage by the way: Sharing strings between components is possible, though I haven’t experimented with it yet. That will be step 2, when looking at the migration of the syncthing-android component.
This would be fantastic . Reusing translations of identical strings so that the app translators aren’t forced to reinvent the wheel (or copy and paste the translations from the main Syncthing translation repo manually…). It would also be great if the wording used in the app was updated to match Syncthing proper (e.g. not “Idle” but “Up-to-Date” for folder/device states, etc.) but that’s probably for the later.
We now have “Public” access status on Weblate. Anyone can start contributing translations as long as they’re signed up with a Hosted Weblate user account:
Please try it out and give feedback if there is anything we should improve or change with the current setup.
We could make separate, restricted groups for reviewing, if there is interest. Right now, I think that no user can set strings to “approved” state.
Playing with it right now. One big difference between the “public” state and Transifex seems to be that now everyone can edit any language instead of only having access to their selected ones…
The site itself appears much lighter and faster than Transifex. Amazingly enough, it also works without JavaScript enabled which is almost unheard in the modern Web .
I’ve encountered one problem so far. I’m trying to fix double and trailing spaces in the two strings at https://hosted.weblate.org/translate/syncthing/gui/pl/?q=has:check. However, the “Fix string” button is greyed out, and the “Save and continue” button is also greyed out even after making manual edits to the strings.
That seems to be the effect of marking strings as “approved”. You cannot change that state because you are not enlisted as a reviewer. However, strings in that state cannot be edited by anyone, which kind of makes sense.
One problem I’ve experienced on Transifex personally when I was just starting was that some strings were marked as “reviewed”, yet the translation was simply wrong (i.e. done by someone without enough fluency in the language), yet I couldn’t fix them as I was just a regular translator. I did suggest corrections, yet the original reviewers didn’t seem to be around anymore, so there was no-one to actually fix the strings.
Because of the above, skipping the review process is probably the only way to get things translated relatively quickly, and also wrong/inconsistent translations fixed as soon as they’re noticed without having to wait for the reviewers to show up (which may not happen). This is especially true for languages where there are only a couple of translators (or literally only one or two at best).
Just my two cents from a translator’s point of view .
) and 2) that it not be worse than Transifex about requiring manual busywork to maintain users and permissions (
).
In my mind it reflects on Weblate, but no; as mentioned it has roughly zero bearing on the whole question about whether to move there.
: I do not like one changes the taste of my coffee. So it’s a nice idea if we have a time overlap to accommodate a new tool.
. Reusing translations of identical strings so that the app translators aren’t forced to reinvent the wheel (or copy and paste the translations from the main Syncthing translation repo manually…). It would also be great if the wording used in the app was updated to match Syncthing proper (e.g. not “Idle” but “Up-to-Date” for folder/device states, etc.) but that’s probably for the later.
.