Translation string location should be hyperlinked if Launchpad hosts the code

I really like this idea. I don't think much (if anything) needs to change on the codehosting side.

We can't do it exactly right, because our references are based on tarballs from Ubuntu packages (or sometimes even on upstream tarballs), but we can approximate. Basically, parameters we have for Ubuntu packages are (distro, distroseries, sourcepackage, path, line number), and for products (product, productseries, path, line number), and if code hosting can provide us with a method to get links based on that, we'd be happy to linkify the references. Note how we _don't_ have the actual revision or release number for the sourcepackage, so everything would be just a guess.

Instead of just linking directly to the source file going further sounds better
Eg a line
Located in ../path/to/file.c:77
should link to all translations within that file (or folder), so that translation can be done per logical units (split into files or folders)

eg above line enriched with such links would become:
Located in <a href="+translate?path=..">..</a>/<a href="+translate?path=../path">path</a>/<a href="+translate?path=../path/to">to</a>/<a href="+translate?path=../path/to/file.c">file.c:<a href="http://code.launchpadp.net/project/trunk/path/to/file.c#77">77</a>

new llinks such as:
- "+translate?path=../path/to/file.c" = listing all translatable strings in that file
- "+translate?path=../path" = listing all translatable strings in that folder
need to be supported

This sounds like a duplicate of bug 2188.

Indeed, bugs are related...

...but this one:
- has a better reasoning (by Данило) why this cannot be done accurately at the moment
- proposes (by Štefan) functionality that is not affected by the above reasoning (or complete lack of sources for that matter), allowing grouping of translatable phrases by files and folders as defined in .po files.