Following up on Translating Syncthing (on Weblate), I’ve started experimenting with the Hosted Weblate setup for the Android app. NOTE that the current setup is for TESTING ONLY, subject to be relocated or to vanish! DO NOT base any work, especially import / export integrations on this project.
So we currently have https://hosted.weblate.org/projects/syncthing-android/android/ as a playground. I intend to move that whole category full of translation components to our official Syncthing project on Hosted Weblate, once we are satisfied with the structure, and workflow integrations are in place to actually import any updated translations from there.
There is even a sub-category for the Syncthing-fork app by @Catfriend1. I think it’s vital to share translations between those apps and Syncthing’s Web GUI as far as possible, to avoid discrepancies further complicating user support. Maybe one day we can reintegrate the fork somehow, and then it will be as easy as deleting the extra sub-category…
So my question now is how we’d want to proceed with the version control integration. Weblate has a myriad of integrations available. I’ve tested their “GitHub pull requests” workflow while originally experimenting with the platform, and it works nicely. An alternative would be direct push access for the Hosted Weblate GitHub user.
I think these integrations are more stable and comfortable than messing with periodically scheduled pull and push scripts from the repository workflows. For one, I won’t have to dig into the automation scripts and adjust them for Weblate. We didn’t choose this path for the main repository (syncthing/syncthing), because there are already other scheduled automation tasks running for documentation and authors list, but for the Android app, I guess we can decide differently.
Which way would you prefer as maintainers of the respective app? Note that the choices can be different, if we don’t find a consensus.
Looking forward to your feedback. We currently have a two-week trial period for the current testing setup.
Thanks for looking into this. I don’t mind much how it works, as long as integrates somewhat painlessly. PR sounds ok - would be good if it could only update the PR every day or week, not whenever a translation is changed as that would be a lot of noise. I didn’t see any options for that in your link, but didn’t dig deeply. If that’s not possible, I think I’d prefer if it pushed to a separate branch without a PR, which can then be merged/cherry-picked, e.g. as part of a release.
I get a page not found error for that weblate link - maybe it’s private still?
Yes I’m pretty sure the PR frequency can be throttled. At least the schedule for committing translation changes can be, which should affect the PR updates just the same.
Sorry I forgot that the new trial project was private by default. Added @imsodin and @calmh as admins, but I couldn’t find a user for @Catfriend1 on there?
What do I need to do to test this? I’m totally new to this solution. From reading this topic, the " new space " will be later able to do PR against my fork github repo, is that correct?
Which steps and info do you need to take our existing transifex translations over?
Sorry, I thought you had more background context already. Added you to the testing project as an admin as well @Catfriend1.
Our Android translations are currently still managed on Transifex, where you have cloned the project to have your own translations in addition. When migrating the upstream syncthing-android project to Hosted Weblate (which Syncthing itself now uses for translations), the existing language files within the app sources will continue to get updated, just from a different platform and using a different push / pull mechanism.
I imagine you regularly merge changes from the upstream Android app into your fork? In that case, you’d get the updated translations “for free”, but only for the common strings. The strings you have added independently can only be handled via your fork, but luckily Weblate allows managing them through the same “translation project”. Thus common strings will be easier to manage and carry over translations between the fork and upstream.
Importing the existing translations from both apps is already done and will continue to get pulled when changes happen in the GitHub repos. Just the step of pushing updated translations back to the repo is yet to be set up.
With what I have planned currently, you will indeed get PRs from Weblate against your repo, applying the updated translations for your project. Any updates for the common strings should be included automatically by propagating between both apps directly on Weblate. If you happen to merge translation changes from the upstream repo before accepting the PR, that should work fine as well, save for any inevitable merge conflicts with neighboring strings.
Just tell me if that sounds like a plan you’d want to follow through with. Then once we have settled on it in the upstream repo, just pull those changes (mostly removing Transifex integration) into your fork and you’ll be good to go. With hopefully more people helping out on both apps’ translations.
P.S.: I’ve tried joining your project on Transifex, but it won’t show up next to the upstream syncthing-android project that I’ve joined as well. Would be good to get access to it so I can examine what losses possibly occur during the migration to Weblate.
I need some more time to actually get this into a working state, so please don’t put too much effort into actual translations yet.
I’ve set the commit age to 70 hours for now, so we don’t get flooded with PR changes. After that period, you should get a PR on your repo, simple as that. It can be expedited by manually triggering a commit in the “Manage” section for the component. But please try not to mess up any settings there
Alright, was just wondering about some strange notification messages. I’m still sorting out the tiny details about XML format handling, language identifier mapping and such. Might make some more noise there in the next few days…
Anyone care to explain how the strings.xml with the English entries is currently managed in the app sources? Is there any build step inserting missing string resources as a template? Or maybe a checker to warn if a key cannot be found in any resource file? What about no longer used strings, do they get removed automatically?
Just wondering because I’ll do some syntactic cleanup on the translated language files to reduce formatting noise when they get adjusted by Weblate. And I wanted to know if the same cleanup should apply to the “source language” file or if that would get overwritten by some automation.
No automation - that’s handled manually. I assume the build step would complain, if a translation string was missing (key used in code but not present in xml file), but I don’t know for sure.
Our trial period ends in approx. 1 day. But I’m satisfied with my current state after these steps:
Cleaned up lots of strings (XML formatting errors mainly, which would otherwise cause noise later).
Cross-checked that all used language codes are valid for their respective domain, renamed otherwise.
Removed languages which are either not supported at all (e.g. in Google Play) or were simply not translated, or duplicate variants.
The results can be seen in the weblate branch: Comparing main...weblate · syncthing/syncthing-android · GitHub, which is also what the Hosted Weblate project is working with. Once we have it in working shape, we can merge this branch through a regular PR (maybe best with a merge commit in this case, to keep the separate change stages traceable). Then point Weblate directly at the main branch.
What’s not done yet is actually disabling any current Transifex integrations. I don’t know how active the project is on there right now. But judging from past experience, merging ongoing changes from there to the weblate branch will be hard work, so we should keep the duplication period as short as possible. Ideally we’ll lock up the Transifex components soon, then try to get the migration done quickly.
First step now will be to relocate the Weblate components to the main Syncthing project (on the “Libre” plan, not trial), which I’ll do just now. Should be easy with their “move this component” function (even across distinct projects), but we’ll see how well it works in practice. NOTE that this will invalidate all previous URLs directly pointing to these Weblate components!
Note that I haven’t worked on the fork any more right now. Will move it over as well (because of the trial period ending), but keep it locked at first until I’ve had time to go over any needed clean-ups / merges there as well.
Reported to the Weblate team through Sentry (which popped up automatically)
ANOTHER UPDATE: Moving worked better when trying each component individually. Now it looks as desired, just that the Catfriend1 fork components still count toward the Enterprise (Trial) billing plan, but should be part of the main project’s Libre plan.
I don’t think we need to worry about transifex, nothing much happened there before the API broke.
Lets merge this after the next stable release, then we have some time to figure any issues without having to care about releases.
I saw you added release note translations on the branch: I don’t think that’s practical, as those change too much. Currently we aren’t translating them.
As for how to merge: Agreed that it makes sense not to squash all those commits. I’d prefer a rebase merge just to keep the linear history. Not an issue, that can all easily be dealt with when it’s time.
I guess if a translation is either missing or outdated for the release notes string, it falls back to the English source string. At least I hope we can configure it that way. That would give translators a chance to do it, but if they don’t catch up in time, will silently fall back to the English source. Let’s see if that works out - we can still just remove the component again if not.
There is no chance: I “write” (not that much prose there) the changelog (Syncthing release always changes) and publish at the same time. And I don’t want to change that unless it’s fully automated.
Good argument So we can remove that component completely. I thought there was some kind of release candidate or testing phase. Note that the fork even has a separate Release Notes (beta) file, which I think should be better handled through distinct branches though.
There is an RC, but the release notes reference the syncthing release. So while there’s a week or so between RC and release, and usually the notes will be mostly the same, the reference to the syncthing release will always differ.
Next step for me is to look at any existing build automation and see if anything needs to be removed / disabled before we can make the switch. But I’ll do that with a fresh pair of eyes tomorrow…
