Thanks again. No issues with locking transifex from my side. And there’s no CI automation, it’s the two scripts to push/pull translations that are run manually. To my understanding there’s no more “pushing”, weblate picks up changes straight from git, and the equivalent of pulling will be merging that PR from weblate. So everything set maybe?!
There have been some additions completing the Basque language again last night. Will pull those in ASAP, which should be a rather small endeavor however.
Well we can just leave the scripts in the repo for now (kept the old transifexdl.go in the main repo as well), then I guess we’re set to go live with Weblate. Will make the announcement on Transifex and Weblate when I’m ready for it.
1 Like
Okay, everything set and announcements posted. Just need a review now to merge the PR and switch over to the main branch.
1 Like
DONE. 
Now @Catfriend1 we need to figure out the next steps to get your fork on the same track. Are you actively merging upstream updates into your fork regularly? The repo layout looks quite different. I suppose it won’t be easy to apply the translation string cleanups, because there will be lots of conflicts. Better to make the same adjustments to your code base first and minimize the diff manually…
1 Like
Hi,
Regarding translations, I don’t take anything from upstream. That lives on Transifex (which we may migrate) with the people who joined as translators and reviewers over time to time.
So I’d suggest a separate project on the target space for it.
Well, the big advantage of having it as a separate “component” within the same “project” on Weblate is that it will correctly identify identical strings. As I have already witnessed today, when correcting some German translations. It displayed a notice that there is a different translation for the same source string, so I could pick which one should be applied to both, or an edit to a common string actually propagates to the other repository. Thus the translators’ time is better spent because they don’t need to do the same work for two different projects.
So my suggestion is to still handle the translations individually, not by merging in patches from the upstream repository. But you will get your own pull requests with changes to your code base and your strings (only the source of the change might be from the same edit as done upstream). Just to ease that process and cause as little noise as possible, I’d carry out the same cleanups I had done to the upstream repo, to your fork. That will actually make it easier to compare which strings differ between the two and reduce noise caused by whitespace differences and other syntax corrections.
Does that sound like a plan? By the way, are you using any automation currently to interact with Transifex, or just the two scripts also used in upstream?
1 Like
Hi,
The scripts (tx_push , tx_pull) currently don’t work. I wanted to try to fetch the transifex translations to github “a last time” , so work since the last sync half a year(?) ago is not lost but did not succeed yet.
I’m currently not taking much time, but your work is very welcome :-).
@acolomb The weblate PR seems to be updated on every change in weblate - shouldn’t it only be updated once every week/day (don’t remember the interval, definitely more than the 2h between the last two updates): Translations update from Hosted Weblate by weblate · Pull Request #1999 · syncthing/syncthing-android · GitHub
Yes, I was a bit surprised by that as well. I’ve set the Age of changes to commit option to 70 hours, but apparently that is not guaranteed to throttle it down, as their documentation describes:
If it does get too annoying we might have to go back to pulling on a schedule or manually.
What is the current state of the Weblate translations? What I mean is that I’m seeing some people very actively update, e.g. the Polish translation of the Fork, and it would be a shame to lose all the work if the current repository is only for testing. Basically, is it safe to translate at the moment or should people wait for now?
It’s all good and working in live production. Since yesterday, we even have the fork app integrated as well.
1 Like
Note that a big advantage of having the two integrated in one Weblate project is that it flags when there are different translations of the same string. You can then choose which one should be propagated to the other components. Updates by default propagate to all identical strings as well, so both apps benefit from future translation fixes without having to do them twice.
I went through the German strings already and propagated improvements from the official app to the fork.
1 Like
In the future, it would be nice to actually re-use many strings from Syncthing proper in the app. There is no reason to have just slightly different wording for the exact some thing in multiple places. There is also some terminology used in the app UI that doesn’t match the Web GUI (e.g. “idle” meaning “up-to-date”, etc.). I’ve always wanted to work on this myself but never had time, esepcially since everything had to be done and verified manually. Now, this kind of unification should be much easier to achieve.
2 Likes
Thank you very much again 
. I had no time to really work on the fork these days but hey, you did the migration perfectly and knowing what to do well 
.
I think I just need to sync my repo now accepting the weblate PR next dev session, cool!
That’s why the “backend” GUI strings are also part of the same project. I actually spotted one of these today with Weblate’s help: “Recent Changes” vs. “Recent changes”. That one’s miniscule, but I know what you mean, there are some contradicting terms floating about. Just saw some more differing terminology today when trying out the syncthing-tray wrapper. But that’s a whole different story, we could extend the concept endlessly I guess…
I’ve just noticed that previously question marks were escaped (\?) but they are no longer so when updated using the new system, e.g.
Is this expected? Does it even matter?
Yes, it matters. The file syntax mandates escaping question marks. Is it shown as \? in the English string? If so, you probably need to replicate that. If not, then Weblate should be handling the escaping automatically, which I thought it did.
I’ve cleaned up any unescaped question mark I could find during the switch to Weblate. Unlikely that they were carried over, and you’re saying this is with a newly changed translation?
It’s unescaped (?) in the English strings, unfortunately.
Yeah, the screenshot comes from https://github.com/syncthing/syncthing-android/commit/a68e451cbec76c56fdc9d01a407c783452a19463 specifically.
1 Like
Then that needs fixing, sorry apparently overlooked some instances.
Hm. In fact, the English string does have the \? in the XML file, but Weblate doesn’t display it. So I assume it should escape translations automatically when changed. If not, that sounds like a bug. Will look into it later today…