WeblateOrg / weblate

Web based localization tool with tight version control integration.
https://weblate.org/
GNU General Public License v3.0
4.64k stars 1.02k forks source link

VCS: Handling of multiple open PRs #12471

Open lars3141 opened 2 months ago

lars3141 commented 2 months ago

Describe the problem

Currently, our workflow with translation management centres around PRs. Whenever a change is made to one or multiple texts, a PR is created as a mean to approve changes made in our language management tool. This leads to rather small PRs, of which multiple can be open at the same time. The current PR-logic of Weblate can apparently not handle this. We would prefer to keep our current process, and are therefore interested in finding a solution in the way Weblate handles PRs. We would need to find a solution for these scenarios:

Our VCR is Bitbucket Cloud, which does not support multiple open PRs from the same branch. This feature request is building upon https://github.com/WeblateOrg/weblate/issues/2344

Describe the solution you would like

My understanding is that we will need to create individual branches for each PR (open to find different solutions). I see 2 options to handle these branches:

  1. Creation of individual branches for every PR. All PRs point toward the push repository.
  2. Checking if there is an open PR on the current branch (no. 1) and creating a new branch (no. 2) from the Tip of no. 1 if necessary. The PR of no. 2 would target no. 1. If no. 1 is merged in the meantime, no. 2 would automatically target the push branch (as described here)

I see no solution to handle rejected PRs. How is this currently handled?

Describe alternatives you have considered

No response

Screenshots

No response

Additional context

No response

nijel commented 2 months ago

This would be tricky for Weblate. Internally, Weblate has cloned the repository and updating it as changes should be committed. This way, everything is easy and history on Weblate side is linear. When doing something more complex, things get messy.

Doing a pull request per language (as described in https://github.com/WeblateOrg/weblate/issues/5563) would be probably doable with some juggling with branches or multi-repo approach.

Doing PR per change generally (1. in your suggestion) doesn't sound doable to me. There would be always a possibility of dependent changes (two users consequently edit the same string). This could also introduce conflicts which would not happen with a linear history (two users changing nearby strings). So this would be complex to implement and complex to handle when merging the pull requests.

Chaining pull requests (2. in your suggestions) seems doable approach as it "only" involves branches juggling on Weblate side and creating more pull requests. This would be incompatible with commit squashing, but should work reasonably well with rebasing or merge commits.

github-actions[bot] commented 2 months ago

This issue has been put aside. It is currently unclear if it will ever be implemented as it seems to cover too narrow of a use case or doesn't seem to fit into Weblate.

Please try to clarify the use case or consider proposing something more generic to make it useful to more users.

nijel commented 2 months ago

What might be a viable implementation approach to this: