Open lars3141 opened 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.
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.
What might be a viable implementation approach to this:
count_outgoing
will need some additional logic to produce reasonable numbers (the new push branch will never exist)
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:
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