Add features to control packages that should generally not be translated (Ubuntu)

I'm talking specifically here about Ubuntu l10n teams that often encounter problems with the paradoxical issue of packages appearing in Rosetta, but that we generally don't want to be translated because upstream does this better.

Most of GNOME and KDE (and others) packages are translated upstream. Some packages need to be translated in Launchpad (update-manager, launchpad integration, documentation, DDTP...). Both groups appear the same in Rosetta when you come from Ubuntu packages; this leads to several issues that are really annoying and reappear every now and then:

- many benevolent users with no much knowledge of Ubuntu make translation suggestions from packages that nobody will ever review because we let this work to upstream; they work will be lost, and they won't understand why. Warning them of this problem would allow them to translate strings that will actually be used.

- some l10n team members sometimes forget that some packages should not be translated. The problem is, they have to permissions to review their proposals themselves: once it is done, translations will not be updated when upstream brings us new ones. This kind of mistake cannot be detected globally, instead the team has to browse packages one by one, and reverse the changes manually. Again, a warning would help much.

We need to be able to correct some strings if there was an error upstream, or a need to adapt packages to Ubuntu. But we could make this less of a problem. Some ideas to solve this:
- add a large red warning at the top of pages that Ubuntu can specify as no to be translated as a general rule, linking to a wiki page explaining what to translate and how, the contacts in your language and so on.

- add a way to use the filter "Changed in Launchpad" in a global distribution way, and not only by package. The idea is if we can see in one click every change made on packages that should be left pristine, we can easily revert this, or correct what changes we made consciously to them (they are likely to be temporary fixes). Maybe a list of recently changed strings in such packages (a little like the SRU list) could be nice too, so that here all the team can review strings.

Maybe this is a complex feature request, but that would help much and avoid spending a lot of time on errors, because ATM this is really a recurrent problem in the teams. Thanks for your work anyway - and maybe you have easier ideas on how to solve that issue.