Tracing who added a source string coming from the repository

[sh-cho]

Changes coming from the repository are attributed to the hook bot user, which as far as I understand is intended (#20108).

What we actually want to know, though, is who added a source string. Right now the history can't answer that at all, and the only way is to go dig through repository history.

Option 1: push-level

Push webhook payloads already carry the pusher and the head commit. From GitHub:

{
  "ref": "refs/heads/main",
  "pusher": { "name": "octocat", "email": "octocat@example.com" },
  "head_commit": {
    "id": "abc1234...",
    "message": "Add new strings for the settings page",
    "url": "https://github.com/octocat/hello/commit/abc1234",
    "author": { "name": "The Octocat", "email": "octocat@example.com", "username": "octocat" },
    "modified": ["locales/en/messages.po"]
  }
}

Weblate keeps only the repository URL and branch from this.

• Keep a few more of those fields and show them on the hook entry
• The history could then link back to the commit that triggered the update

This doesn't tell you who wrote a given string, only what push brought it in. In practice that's usually enough to find the person, and it looks cheap.

Option 2: per-string

Actually attributing each string to its author. This is what one really wants, but the cost looks very high:

• Weblate diffs whole files rather than reading commits, so there's no commit-to-string mapping to begin with
• A single pull can span many commits, and forges truncate the commit list
• Forge identities would have to be mapped onto Weblate users

Getting it right would probably mean going to the local clone and blaming per string. Personally I doubt this is worth it, and I'm not even convinced it would be accurate: PO files get regenerated by xgettext / msgmerge, so blame frequently points at whoever last ran the extraction rather than at the person who wrote the text.

So option 1 seems like the reasonable target, even though it's really just a workaround for option 2. Would that be worth doing on its own?

[michael-smt]

I'm not a fan of this because both options take untrusted user information from other platforms. Option 1 is highly platform dependent, while option 2 can become quite complex I think.

How about just setting the repository browser URL to directly point to the "git blame" view of your code hosting platform, that would make the digging through repository history less cumbersome 🙂

(Side note: the repository browser feature should support a sha placeholder from upstream to make it more accurate tho...)