Local translations
Closed, InvalidPublic


Phabricator allows local translations in the configuration, which can help to solve issues that were WONTFIXed upstream while not needing to maintain local patches.

This would need phabricator/maniphests/init.pp to load an additional file with translations, just like base settings are loaded from fixed_settings.yaml.

Currently there are already a few local translations in fixed_settings.yaml, so they could also be added there: https://github.com/wikimedia/operations-puppet/blob/a87adae3e33d725260a00b3b8e5e38c701180903/modules/phabricator/data/fixed_settings.yaml#L176

valhallasw updated the task description. (Show Details)
valhallasw raised the priority of this task from to Needs Triage.
valhallasw added a project: Phabricator.
valhallasw added a subscriber: valhallasw.
valhallasw updated the task description. (Show Details)Jan 9 2015, 7:52 AM
valhallasw set Security to None.
valhallasw updated the task description. (Show Details)Jan 9 2015, 7:55 AM
Qgil added a subscriber: Qgil.Jan 9 2015, 12:35 PM

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.

Qgil moved this task from To Triage to Need discussion on the Phabricator board.Jan 9 2015, 12:35 PM

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.

mmodell added a subscriber: mmodell.Jan 9 2015, 7:50 PM

why not use tags for tracking related bugs?

Qgil added a comment.Jan 12 2015, 7:40 AM

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.

valhallasw closed this task as Invalid.Jan 12 2015, 1:12 PM
valhallasw claimed this task.