The discussion addresses the challenge of finding context for translating text when historical data is obscured by release folder migrations. Moin initially explained that while translation history previously allowed quick identification of Pull Requests (PRs) via timestamps, recent changes now incorrectly timestamp all pre-release texts, hindering this workflow. Seeking a solution, Moin received a prototype tool from gerhard that directly links strings to their PRs, significantly streamlining the process. stephtara joined to ask for clarification on the term “PR,” which zogstrip defined as a GitHub Pull Request. Moin noted that while the tool was a vast improvement, it initially displayed incorrect “removed” statuses for strings in the release branch where no removal logs existed. gerhard acknowledged the prototype nature of the tool and began fixing bugs. Subsequent testing by Moin revealed inconsistencies regarding backported security PRs and stale git data. gerhard resolved these by updating the tool to display both latest and release branch PRs and clarifying when strings were merely moved. After further feedback from Moin regarding specific strings appearing removed without evidence, gerhard fixed issues related to stale data imports. Final minor UI issues regarding the “removed” label were also addressed by gerhard. The discussion concluded with Moin asking about update frequencies, to which gerhard explained that a temporary delay was caused by a background job backfilling AI-generated context, expected to resolve within a day.
When I wanted more context for translating a text, I usually looked at the translation history. There I could see when the text was added, and with the date and time I could often find the PR on GitHub very quickly. Often the description there is helpful enough, and sometimes there are even screenshots and videos that make the context very clear. If that doesn’t help, at least you can find the relevant code sections very easily.
Unfortunately, this workflow now only works to a very limited extent for me. For new texts, I can still find out when they were added.
However, when the release was made, all texts were moved to the release folder, which is why all texts created before are now shown as having been added to the project on 2026-01-28T17:22:00Z. This does not help me to find the PR quickly.
Everything is fine. It doesn’t matter for my purposes. I just thought I’d note it here if I noticed anything. I actually still have to get used to how easily I can now find the associated Pull Request. Before, I often weighed whether it was worth the effort to search for the Pull Request and decided against it. Now it’s just a few clicks, I sometimes still forget that. Recently, the change history was even very helpful because Crowdin didn’t show the previous text, but the previous version was helpful enough as context so that I could save the step to the Pull Request.
Maybe this is the same bug, but since here there is not only a log about the text being removed (while I cannot spot the string in the changelog of the PR), there is also a log about the text being re-added where I have the same problem. Maybe this example helps to find the bug.
Okay, I resolved the issues with missing entries in the git history and commits appearing as removed when they actually weren’t.
This turned out to be an interesting case. The change was backported to the release branch, so the commits shown were technically correct. They simply have different git hashes.
To make this clearer, I’m now showing both PRs for each branch.
I also cleaned up a number of smaller issues. You’ll now see whether a commit belongs only to latest or to both branches, and it will indicate when a string was merely moved to a different file without any actual changes.
Usually it takes only a few minutes, but I’m currently running a background job to backfill AI-generated context for each string. This temporarily prevents some features from working correctly, but everything should resolve itself within a day or so.