Fix Transifex config to make pull script work again.

[acolomb]

Just needed an update to the config file syntax. Now the tx_pull_translations.cmd command works again for me, as witnessed by the updated translation files.

Related to https://github.com/syncthing/syncthing-android/pull/1993.

[acolomb]

So this is the first step towards migration to Weblate for translations, first fixing the existing Transifex integration along the way.

I encountered some unexpected troubles along the way. Frankly I was stomped by how many differences there are to the official Android wrapper repo. The fork doesn't even appear as a fork on GitHub, but rather an independent project with a partly identical history. That can't be changed easily in retrospect though, it just makes doing Pull Requests against both forks harder than it needs to be. I now forked this repo as well on GitHub, to manage PRs for both projects.

The next big thing is that this fork seems to be developed more on Windows systems. That's fine, although using the upstream Bash scripts for translations (e.g. on WSL) would make it easier to carry over changes from upstream, instead of replacing them completely with CMD script variants (which I cannot even run on Linux). I haven't investigated what exactly or why some directory structures were moved around, such as the scripts no longer living in scripts/?

It also causes EOL style troubles for me. Importing from Transifex changed all files to CRLF line endings. I had to do some Git magic to fix that. Probably pushing the translations to Transifex once with proper LF line endings would fix that once and for all. The repository internally (and as such also Weblate) uses Git's standard LF line endings, thus we should fix Transifex to do the same. If you want, I can try to make the necessary adjustments on Transifex, if you give me sufficient access rights.

I really want to work together with you to reduce these differences and make the development acrosss forks easier. Are you willing to go in that direction?

[Catfriend1]

@acolomb

Thanks for assisting me. Sure, I currently do not spend much time with the fork but we could so step by step.

Some quick overview for you: I do not insist on crlf, except for the batch scripts. It's right I'm mainly using windows today to develop and build. In the first days of my work on the app, I just used Debian Linux via smb share , shell and it was my main builder. This changed over time to windows as I got used to Android Studio and Atom instead of notepad2 to edit the files. CRLF seems a config issue, so feel free to edit .gitattributes etc accordingly and propose it to me. As long my build on windows works, I'd happily accept. :-).

If you need bash scripts from upstream, I remember imsodin did a good job on this the last years, just fetch them over here as well. I did not copy his work as I did not need it (no docker here).

We now still miss some source strings in Transifex. Should I run the push during my next dev session as we already had the pull now?

The fork originally was a fork repo. But differences grew up over years and I've made two or three attempts to PR main fixes and functionality to upstream that I finally gave up (no offense intended). Always when I tried to make a fresh PR (merge fork into upstream) I had hours of work, ending up, that they are so different now, it would almost be the same instead of selecting commits and fix the mess until they are 90% technically the same and differ 10% visually it would be better to "full copy" everything and name it "stable" .

[acolomb]

Well, ideally you should use LF line endings for the next TX push operation. I could do it naturally, as I'm on Linux. Just need the write / admin access to Transifex. I guess it doesn't do much harm since we want to switch to Weblate anyway. But I'd rather reach a clean slate again before working on the required clean-ups and the transition.

Sorry I don't quite understand your last paragraph about PRing fixes from fork to upstream. I think the more important direction at first is the opposite: For the fork to pick up upstream fixes as well.

[Catfriend1]

@acolomb

Yeah, the PR to upstream is a long history.... No problem 🙂.

Which fixes did I miss? I think I've pulled some rare PR in from upstream from time to time, when bugs were fixed there which also affected the fork. But you are righr: script, build, translation related things were skipped.

Just tell me what you need merged from upstream?

[acolomb]

Oh it was more a general comment, I haven't looked into the actual history differences yet. I just think it would be helpful if we could occasionally do git merge upstream/main without resolving tons of conflicts every time. If that is done regularly, it makes it much easier to see the actual differences and also keep conflicts low for the next invocation. Git really helps in that regard, but you need to do it regularly.

I've been maintaining a (closed source) project with Git for years where a product variant requires an internal "fork". The long-term goal is to reintegrate all changes as build-time options into the original code base, but in the meantime, I regularly merge the upstream main branch into the fork and usually try to fix bugs upstream first to have both variants benefit. So it's quite similar to the situation here and the upstream to fork merging is essential in my experience.

Let's concentrate on the translation stuff first and I can make individual PRs for diffs discovered along the way.

[Catfriend1]

That's a good suggestion. First start with translations and the rest we can see what pops up and then decide if a merge is mandatory or optional.

[acolomb]

How about that push access to your Transifex project then? I've been cleanup up existing translations now, but just in case we should check whether anything new pops up after a push-pull cycle there. Or you just do the pushing and I can pull the differences then and compare locally...

By the way, clean-ups so far are at https://github.com/acolomb/syncthing-fork-android/tree/fork/weblate and I think there are some worthwhile fixes in there - mainly syntax errors and cosmetics, but also whole language translations being untouched and scheduled for removal. Those were too easy to add on Transifex I guess, so people joined the language team but never actually worked on them.

[acolomb]

Oh, if you do, please push with EOL-style = LF (UNIX).

And do we need translations for the release notes actually? We dropped them in the upstream app, not sure if they would be useful to you? At first I had imported them from Transifex, but there are no actual translations.

[Catfriend1]

How do I grant push access? I have no time to go deep in it and am just on the phone right now. Will see what I can fasten to assist you.

But will take some days until back on PC.

Release notes translation is not important in my point of view.

[acolomb]

Alright, seems to have worked. I couldn't upload the current source strings using tx push, that resulted in an error: 409, conflict: This action cannot be performed because resource is not accepting translations. However I could upload the source strings file manually. Pulling translations afterward yielded no changes though.

[acolomb]

Sorry that 409 was a red herring, I was working in the wrong directory and talking to the upstream Transifex instance. Now checking out with the correct project.

[acolomb]

Okay, I finished my PR for the migration, see #1032. Locked the resources on Transifex now, to avoid getting more changes there which we'll need to carry over. An announcement will need to be put on the old Transifex home, to direct people to the new Hosted Weblate platform.

[Catfriend1]

Hmm maybe I will just delete the old Transifex thing when the migration is over... Is it now sure, the Syncthing project will stay on weblate?

[acolomb]

Well, it's been some months now and I can't remember many complaints about the switch. IMHO the Weblate platform is much more capable and led to real improvements regarding the quality of translation already. Under those circumstances, I think it highly unlikely that someone will step up and put in the effort for yet another migration.

I guess deleting the project on Transifex would work, but whoever returns there after maybe having contributed some time ago would be better off finding a pointer to Weblate instead of a 404 page.