“The integration will make one commit per language”
However it seems to be one commit per resource per language. On a project with 40+ resources in 3+ languages, this turns into a lot of PRs very quickly, even if we wait for resources to be 100% translated and reviewed before the PR is made. Is there any way we can have the integration group the per-resource commits into a single PR? Not being able to batch them is pretty much a dealbreaker for using the integration at the moment, as there is just too much overhead for someone to merge them all, not to mention noise in the github UI. (Having the integration commit directly is not possible as it is a protected branch.)
Thank you for your message, and for bringing this documentation bug to our attention.
A PR is created for every resource/language where the update takes place. Unfortunately, for the time being, we do not support the option of sending these updates in a single PR or schedule sync between GitHub and Transifex but I completely understand the need behind this request.
I will forward your comments to the rest of the team so that the current behavior will be evaluated further and decide how we can better address this in the future.
Thank you in advance for your patience and your cooperation.
Hi @Panagiotis_Kavrakis
I tried this week-end the new settings and while you indeed have a single PR to deal with, you still have the noise of the tens or hundreds of commits notifications that gradually fill that PR.
I think one great improvement would be ability to schedule when translations are pulled back to the repository, and have creation of a single commit for all the translated files. This would apply to both the “Commit directly” and “Create a pull request” options. In my case for example, I don’t need tranlations in the repo as soon as they are filled, I just need them to be available when the schedule build process starts.
I am Antonis from the Transifex Customer Success team. I hope you’re well!
If you scroll a little further below there’s also an option to introduce an interval between commits (between 1 and 60 minutes). This aggregates all changes made in that time period and combines them in a single commit.
While scheduling isn’t currently an option you could also have your integration to sync your resources once they are 100% proofread for example but only mark them as proofread when you wish to sync them to your repo as a workaround.
Please let me know if this is a good alternative to scheduling when translations will be synced to your repo. If you have any additional feedback I would be happy to discuss this further with you.
Hi @Mylon,
I’m fine, thanks. Hope it is the same for you.
I can’t remember if I had it set before or after the flood, but here the PR that made me worry about the noise (OK, I was initiating a new integration) and reinstate the direct commit route, instead of going through PRs.
However I don’t have the same understanding and experience with that option (I set to 15mn):
In my understanding, the single commit happens within the same file: that is, I translated a resource and reached 100%. Instead of automatically pull, it allows me to adjust more translations in the file, e.g. because there were some errors, and after 15mn of inactivity the translation is pulled to gh. At least this is the impression I had today testing that config: no immediate pull was generated after I first reached 100% of translation of the file.
For example, let’s say that you’ve set the commit interval to 10 minutes. Within those 10 minutes, you make several translation edits in a resource file. Instead of individual commits for each change, you’ll receive a single commit after the 10-minute interval expires, including all the latest updates. If you continue to edit the same translations, a new commit will be generated after another 10 minutes, grouping all changes made during that time.
If you watch the branch history in Github, the interval beteen commits is lower than the 15 mn set; and I still feel like it is one commit <=> one file.
While scheduling isn’t currently an option you could also have your integration to sync your resources once they are 100% proofread for example but only mark them as proofread when you wish to sync them to your repo as a workaround.
I’m afraid that anything that would require manual tweaks before the build that occurs automatically, daily, wouldn’t be an option.
I see what you mean a bit better now and I hope I can offer an explanation that answers your questions.
If you have set the option to generate a PR, depending on what grouping you set you will either have one PR for everything, one per language, one per resource, or no grouping at all. Direct commits will simply skip all that.
The GitHub integration will generate a commit for each language of a resource (each distinct translation file). What the interval between commits allows is to reduce or eliminate multiple commits for a single target language. When you set a 15 minute interval between commits, the GitHub integration checks every 15 minutes for any 100% translated file and syncs them by creating one commit per language per file/resource.
This is a middle ground giving you the option to quickly overview all updated translation files while not generating unnecessary clutter like single string commits.
You can squash all those commits together before or during a merge (squash and merge) though this can’t be automated through our integration currently. If this is something you’d like to see as an option please let me know and I will share it with the rest of the team.
Hi Mylon
Exactly. You confirm the way I understand the option: one commit for one file within the duration you set. So you may now get less commits but I’m not convinced it addresses my remarks, although I agree that having ability to group them all within a single PR is in the repo management.
You can squash all those commits together before or during a merge (squash and merge) though this can’t be automated through our integration currently. If this is something you’d like to see as an option please let me know and I will share it with the rest of the team.
Yes, in the case you are using PR, you can still squash the commits and reduce the number of commits in the branch, but this doesn’t prevent the repo followers to get notifications for each fully translated file that Transifex sends to GitHub as a commit. And this is what I called the noise, and where I think Transifex would do a really greater job if instead of sending tens of commits a day, it aggregates the changes in a single commit and sends to github at a predefined custom time (this time can be at a specific hour or an interval, or whatever).
Hope that clarifies.
I will share your feedback to our product team for consideration. Since they are similar yet different features, if we decide to include these options they may not be available in the same release but I can definitely see the value of both.
in the repo management.