Anyone is welcome to contribute translations for Syncthing. Just sign up at Hosted Weblate and get started on any existing language. The base (source) language is English, but you can easily cross-check from other already translated languages that you know. New languages can be requested using the Start new translation button at the bottom, but need approval from a maintainer.
Note that there is no formal review process, so please get in touch directly with others working on your language if there are disagreements and try working together.
The previously used translation platform, Transifex, is currently still in use for the Android app component. We plan to migrate that as well in the coming months.
Rebasing (1/57)
dropping e48b1e85bf16d70627a988144829813130861545 Translated using Weblate (Valencian) -- patch contents already upstream
Rebasing (2/57)
dropping 27dca4c65e9e4acac0290e3de5d19b0a1b569815 Translated using Weblate (Czech) -- patch contents already upstream
Rebasing (3/57)
dropping e17517f74b2a834e42a7889d15c1ea203b522cf8 Translated using Weblate (Danish) -- patch contents already upstream
Rebasing (4/57)
error: could not apply 63960e33b... Translated using Weblate (German)
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 63960e33b... Translated using Weblate (German)
Auto-merging gui/default/assets/lang/lang-de.json
CONFLICT (content): Merge conflict in gui/default/assets/lang/lang-de.json
(1)
So it seems the automatic retrieval and committing of changes to our main repository creates conflicts when Weblate tries to rebase its commits on top of the updated upstream branch where they are already contained. Merging works fine however, so I switched it over to try a merge instead of a rebase. That fixed the immediate error, let’s see how it behaves in the coming weeks.
@acolomb I got some errors from the syncthing-android transifex script a while ago, probably the API upgrade/deprecation you mentioned at some point. Would it be possible to move syncthing-android translations too? Just gauging whether I should try to fix those scripts (at some point, no prio/hurry at all on my side) or if this could fix 2 issues at the same time.
It’s definitely possible and still on my agenda. However the first prerequisite in my head is to get a local build of syncthing-android set up at all. Thus being able to investigate how it interacts with the translation system at all. Being a total Android app development novice, this is not a small task. Sorry I can’t give you an estimate on when I’ll have time for it.
If there is a good tutorial on how to get started / a summary of how i18n and Transifex integration currently works for the Android app, that would be a great starting point for me.
on phone atm, everything from memory, can give a better explanation next week:
top-level readme has instructions to build of you want to manually set everything up. alternative is using docker, there are instructions in the readme in that sub dir, or using android studio. i’d recommend docker.
scripts to push/pull translations are in the scripts dir. i believe the translation string filnames/structure is an android standard.
That’s perfectly normal AFAICT. It’s caused by how we interact with Weblate through scripts. It appeared about 2 weeks ago because that’s when I last reset the Weblate internal Git repo to the upstream state.
Weblate creates separate commits for each language update regularly. It could propose them for merging in a PR, as we’ll tentatively be doing for the Android app. But here we just download the latest end result from Weblate regularly and commit that to the upstream repo. Weblate notices that and merges the upstream main branch into its internal branch. Which pretty much always works without conflicts. But officially, the Weblate internal branch and main are not the same at that point, because of different history lines.
We could switch to Weblate doing a rebase instead of merging, which should end up eradicating any outstanding changes in the Weblate branch and just make them identical again. However, that actually does cause conflicts regularly. Because even though the end result of the rebase should be identical to the latest upstream commit (where the JSON files were imported), Git still tries to replay each individual commit that Weblate recorded. Somewhere in between, conflicts arise because of neighboring changes or possibly keys added upstream. So instead we switched to the “merge” setting and live with the warning that the upstream branch is diverting in history from what Weblate is working with.
Everything should still be working normally despite the alert.
If yes, it might have too low completion. Languages get filtered out if less than 75 % of the strings are translated. You can help reach the required 95 % again by contributing there on Weblate. It should then show up in the next released version.
If it’s not yet among the translations, you will need to start a new one. Refer to the available language codes here: https://github.com/WeblateOrg/language-data/blob/main/languages.csv, we can easily add new ones (for people to work on though, there is no professional translation team ).
Hopefully it will be supported at some point, I did it because I can mainly, and Arabic support -despite being a major language- is terrible almost everywhere, so I’m trying to improve it as much as I can.
.
).
