Increase visibility of new strings before they are committed in GitHub

• Jan 20, 2020 - 10:59

I had an idea on how to improve the quality of strings or involve users with an English language inclination during the pre-merge part of the dev cycle (e.g. before new strings hit Transifex for translation):

Problem: when new or changed strings hit Transifex, they have already been merged into the source tree. To get them changed would require a new round of discussion (forum or Telegram), optional issue, then a PR, which may take a while to be merged.

If we have a "strings" label which we assign to PRs that contain new or modified strings, non-coders such as myself could identify those string-PRs, have a look and make sure that we are OK with the strings about to be committed, or help improve them before they are. I am not talking about a formal review process (e.g. that someone has to sign off on the strings, but would not be against it) just making it easy for language-sensitive contributors to give their input. In the past, I have tried looking at PRs but find it just too cumbersome to manually identify the ones that do have strings because they are such a small %, and of those a small % could benefit some tweaking.

Even better would be to be able to subscribe to a label (e.g. I am automatically on the thread of or get notified of all PRs with the "strings" label.)

The "strings" label would also give more visibility to PRs that would trigger translations, and would make a string freeze before a release easier to implement.

This would not be limited to translators, but to anyone with an English "language sensitivity" or opinion, and who would be willing to help improve the strings, could potentially get involved.


This sounds like a good idea to me! Perhaps people submitting PRs could prefix the title with "[string]"? That would save the dev team from having to tag PRs manually.

In reply to by shoogle

Thanks. I also thought about the logistics of tagging PRs. I am hesitant to introduce/impose another formal requirement for the title, similar to "Fix #1234567". And any that don't have it have to be reviewed anyway. If the ability/permission to label could be delegated to someone (I put my hand up) it would take the load off the devs with merge privileges.

Also, to be sure that a PR that does not have strings has been reviewed and found to have none, a "nostrings" label might also make sense. Without it, one would have no way of telling if it has no strings or is yet to be looked at, and can cause duplication of work.

Do you still have an unanswered question? Please log in first to post your question.