I might be missing something, but we are already using localization to fix i.e. T798: Change "Real Name" string for "Also Known As", and I don't see how this would be the solution for tasks like T84833, where new UI elements need to be created.

I got the blockers the wrong way around -- I meant this as tracking task for 'tasks that should be resolved / have been resolved by using a local translation'.

What is the usecase for a tracking bug for "tasks that have been resolved by using a local translation"?
(And who plans to keep its list of dependency tasks up to date and complete?)

The use case is a) linking related bugs together without having to copy-paste all bugs to all other bugs, and b) allowing one to figure out how the issue was tackled in other cases.

why not use tags for tracking related bugs?

To the original point, we are already using Local translations to modify UI strings, so I'm not sure why we need to keep this generic task open.

Every tracking task (this should be marked as tracking btw if it is one) takes someone's time to keep it updated, otherwise its value erodes.

So... if someone files a request to change a string in Phab (without searching existing tickets), likely someone else will point out how to achieve it. If someone searches for string changes, they might find one of those tasks listed as dependencies here, and the corresponding Gerrit links explaining how to make such a change. And if someone has already requested a string change in Phab, that someone will likely be able to find her/his previous task to see how things worked.
This very task currently already requires knowledge that something like "local translations" exist and that it is used to change strings. So you already need to be aware of implementation details. So you likely already know anyway how things work.

I'm also proposing to close this ticket as I don't see a good reason to track such stuff - the Gerrit file is a way better place to not duplicate efforts if we don't want to track stuff for the sake of tracking.