Archisteamfarm: Separate branch for localizations

[PhyxionNL]

Currently it's almost impossible to find commits with changes to the program, due to the huge amount of localization entries. Would it be possible to create a separate branch for localizations (which can then only be merged occasionally)?

[JustArchi]

There is separate branch for localization entries - l10n. I do not have a direct choice how pull requests are handled, as that part relies on Crowdin without many options, basically GitHub integration or not.

And GitHub integration is very important for me, as it allows me to develop program, add new strings and ensure they all land in strings to translate, without my helpful hand or manually updating them every once in a while. I didn't go crazy from all of that yet thanks to that fact and how it's all done - I develop ASF as usual, and I only merge ongoing pull request when I'm about to make a release or just feel like it. It's perfect, if I had to remind myself to update strings and translations every once in a while manually, I'd probably drop this idea entirely.

So while I can't really do much with l10n branch and PR itself, as that would mean abandoning GitHub integration and making more hassle for me, there is still something I can do - picking merge & squash option instead of merging only in PR, which will result in a history like this.

I must check how exactly squashing affects integration, but if it doesn't cause any problems, then it solves your problem in 100%. I'll close this issue once I'm sure this can work.

[JustArchi]

Squashing won't do, it breaks entire history later on, and causes me more trouble, which is what I want to avoid in the first place.

Hey!

I'm working with you translation platform and it's great, I'm enjoying it very much and the fact that you support open-source projects really makes me happy!

I'm currently using GitHub integration for syncing my project, and it works really great for syncing strings, but I have some issues with automatically generated pull requests. In general every single crowdin action results in a commit - if I keep this PR open for several days, it's entirely cluttered with commits, and merging it later to the target branch clutters it as well. I could squash that PR, but then l10n branch that is being used for Crowdin commits is out of the sync with main branch (has conflicts), and dealing with entire situation is even worse.

Could you please consider adding a setting that would allow to "bundle" Crowdin changes together, in a single commit, in given time interval? For example, I could pick "1 day" option, that would limit Crowdin into 1 commit per day, bundling all changes done in the meantime automatically. It would delay some changes, but thanks to that keeping history clean, as merging such PR later on won't result in merging 300+ commits made across 2-3 days.

Alternatively, if above is too troublesome, maybe you could add an option of disabling creating/maintaining localization branch + sending PRs, so I could still use GitHub integration for synchronization of strings, but update outcome localizations myself in a single commit. Currently it's either "all" or "nothing", and I don't want to drop it entirely only because Crowdin is too "noisy" when it comes to sending PRs :). If it's possible for you to implement bundling suggestion, that would be great, but I'll be also very happy if I can simply disable localization branch and maintain localizations myself, while still using strings syncing provided by you for translation on the platform.

Sincerely,
~Łukasz

But I sent an e-mail, so we'll see if it will be possible to save me hassle in the future. Currently it has to stay like this if I don't want to go crazy doing everything manually.

[JustArchi]

Hello Łukasz,

I will forward your suggestion to our devs team and ask whether it is possible at least to add an option of disabling creating/maintaining localization branch + sending PRs as you mentioned.

Hopefully, I will update you today on the matter, thank you!

Have a great day :)

[JustArchi]

Hello Łukasz,

I just want to update you regarding our conversation about branch localization.

I forwarded your suggestion to our devs and they really consider to be a great idea although it is not planned to be implemented in the near future since it's a kind of time-consuming procedure. It is included in our list of future improvements, but unfortunately, I can't guarantee it is implemented in the short run.

Thank you again for a suggestion, it does make sense, so hopefully we can put it into life someday!

Have a lovely weekend!

[PhyxionNL]

You could perhaps add a separate project for localizations, there are quite some projects doing this.

[JustArchi]

And add myself extra work I want to avoid in the first place only to allow people viewing commits more easily? No thank you.

[PhyxionNL]

This link can be used to filter out translations. It's not as clear as the normal view but it's better than with 10000 translation messages in between.

[PhyxionNL]

Let's hope Crowdin adds that feature in the future, I think that would make everyone (regardless of which project) very happy.

[JustArchi]

I'm not against this suggestion and I also hope that they add it sooner than later, but you should also understand my reasoning - I want to minimize maintenance work I have in ASF, not add myself extra one. There is little difference between merging translations from other project and maintaining strings fully manually. The way it's right now makes it much easier for me to manage them without much hassle, which doesn't automatically mean that I can't see a problem, as I'd appreciate less clutter in commits history as well. Therefore, we're waiting until something better happens.

[JustArchi]

Eventually I got annoyed enough myself to drop GitHub integration until it'll have an option to spam less. I'll update translations periodically myself until then.

[JustArchi]

I even managed to get best of both worlds 😀