Comment 8 for bug 317136

> Trying to solve it using the URL scheme is unlikely to yield great
> results. The current long URLs are verbose, but have the advantage of
> being memorable and transparent. If we try to change them we'll end up
> in an arms race where we never get significant improvements (significant
> enough to remove the requirement for a real tiny URL) and the URL scheme
> for LP as a whole is becoming baroque.

I agree.

One of the things that Launchpad has been praised for is the quality
of its URLs. They're easy to build as long as you know the general
rules of their structure.

That said it would be nice if any shortcut URLs we produced were of a
memorable (if not necessarily guessable or hackable) format.
http://linkpot.net does this nicely by using dictionary words,
although by choosing to do that you then impose a natural limit on
yourself. Also, it has a tendency to pick really inappropriate words.

Maybe one option would be to go with something like:

http://shortcuts.launchpad.net/$object_abbreviation/$object_identifier

Where $object_abbreviation could be something like 'br' for a branch,
'mp' for a merge proposal and so on. $object_identifier is more
difficult; we don't want to expose DB IDs in URLs (unless we already
do so, say for merge proposals). For a merge proposal, you could have:

http://shortcuts.launchpad.net/mp/1234

But for branches you need to worry about the Person and Product to
which they belong, too, so I'm not sure what The Right Way to do that
is (if we went with sc.lp.n/br/~foo/$product/$branch we're actually
going to end up with a longer URL than we would if they just used
code.lp.n...).