FileSender v3 poeditor breaks langauge import for 3.x series

[monkeyiq]

This relates to the "Rearrange poeditor translation setup for v3" https://github.com/filesender/filesender/issues/1517

I thought I would put my past procedure and thoughts here so we can work out what the plan is going to be for the v3 translations. Maybe if we update the language handling scripts we only do that in the 3.x series and leave the 2.x series using existing old method?

In the past the translations for the 2.x and 3.x series were both in the same poeditor project. I was using the work flow to import all the translations into development from poeditor using a script. That took care of the 2.x series.

The 3.x series has development3 which is a branch of the 2.x series development in git. The development gets merged into the development3 from time to time and the ensuing conflicts fixed to make updated 3.x series releases. This merge was also bringing in the updated translations from poeditor from the 2.x series automatically.

It is possible to update the import script to be run directly against development3 and import the FileSender v3 from poeditor into that. This is likely to result in a bunch of conflicts to resolve at git d2/d3 merge time. That merge issue may be able to be resolved by auto selecting the version of the language subdir tree from development3 in the case of a conflict. Though as I mentioned above, maybe we don't want to continue to use the auto import script in 3.x.

[WebSpider]

Looking at the changes in the 'defaultish' en_AU language in #1530 it's clear we need some sort of distinction between the 2.x series and the 3.x series: Language use is different, so same strings have a different translation. Overall it seems to become a bit less formal, with results in many spots in the UI/translation.

I like your suggestion of reusing the scripts we have (at least initially), pointing to the new project. It saves time, and we can rearrange this as we see fit with the considerations from #1517. Importing language translations using the script seems to be a simple solution. This is less trivial to setup correctly and maintain correctly using CI. But if we have this setup correctly, it will take a maintenance burden away, since translations can then be auto-imported in the release-process.

I see your point of returning merge conflicts between d2 and d3 branches on updates, so i guess we need to decide how we go forward here.

One option might be to do a final sync of d2 to d3, and from that point only do cherry-picking of changes/commits from d2 to d3. We know the majority of changes in d3 will be UI related until 3.x gets released, so in theory, this shouldn't result in many merge conflicts. YMMV offcourse. From then, d3 would take language updates from the poeditor v3 project, instead of the v2 project.

This would involve some communication, since we would then effectively be promoting d3 to the new baseline for development, and demoting d2 to the future status of the 2.x line

A other option might be to accept that there will be conflicts. I've done this in a branch for a specific implementation of filesender for a few months, and the extra maintenance involved doing the merges gets to be a drag pretty quick. For me, this would only be an option if we know we don't need to do many additional merges.