← Back to team overview

launchpad-dev team mailing list archive

Re: App-specific pages accessed on the mainsite

 

Hi Salgado,

У пет, 14. 08 2009. у 17:54 -0300, Guilherme Salgado пише:

> While fixing our breadcrumb infrastructure to be able to generate the
> breadcrumbs listed on https://wiki.canonical.com/Launchpad/UI/Navigation
> I came across these three pages that behave differently when accessed on
> the mainsite instead of the vhost they were intended to be.
> 
> 1. The +translate page for an IPOFile is a view which redirects me to
>    the same URL on the translations vhost.
>    https://edge.launchpad.net/tangocms/trunk/+pots/tangocms-aliases/es/+translate

That one is historical: we've got a bunch of URLs like this since
translations was there since very early in the time, when there were no
separate vhosts (well, even since the webhost was
launchpad.ubuntu.com :).  Redirects were introduced so existing links
did not get broken, and that was around 3 years ago now.

I was actually hoping to get rid of the redirection sometime soon (i.e.
I got reminded to it when doing rosetta-tree-reorg).

> 2. An IBug's +index page is available on the mainsite just like it is
>    on bugs.launchpad.net:
>    https://edge.launchpad.net/bzr/+bug/165293
> 
> 3. And the +index page of an IDistroSeriesLanguage is only available on 
>    the translations vhost, so trying to access it on mainsite will 404.
>    https://edge.launchpad.net/ubuntu/jaunty/+lang/af

That page is slightly newer, so it's available only on the translations
facet.

> I think it makes sense to always do like 1 and redirect to the
> appropriate vhost, so I'm wondering if there's any reason for 2 not
> redirecting and for 3 not being available on the mainsite or
> redirecting?

"Always" is impossible (eg. translations.launchpad.net/ubuntu is
different from launchpad.net/ubuntu which is different from
bugs.launchpad.net/ubuntu), so I'd worry about this only for the most
relevant pages where we want to enable nice URLs for manual typing.
DistroSeriesLanguage page might be one of those, but POFile:+translate
page definitely isn't.

> If it makes sense to have 2 and 3 behave like 1, would it make sense to
> have all the app-specific pages behave this way? (I haven't yet
> considered how easy/difficult it'd be to do so)

I'd say no.

> If you're wondering why I care about this, it's because we kind of need
> that if we want to have a generic solution for generating the
> breadcrumbs for all (most, in fact) different objects.

Which is an completely different problem we need to solve.  Martin has
long advocated having all Person links on different facets link directly
to the main host, but considering how translations.launchpad.net/~person
is useful when you are dealing with translations, we want this to remain
as is (we are actually turning it into a personal dashboard for that
translator, hoping later to turn the homepage into dashboard, but that's
future material).

Ideally, though, what we'd have is an ability to plug a switch to
translations facet anywhere in the trail of breadcrumbs.

Eg. on ~person page, that'd be something like:

  Launchpad.net > Person > *Translations*

On IDistroSeriesLanguage, it'd be something like:

  Launchpad.net > Ubuntu > Jaunty > *Translations* > Serbian

etc, etc.

So, we'd want to insert it right behind the context object, where those
context objects are main things we can have translations on/by (i.e.
Person/Team, DistroSeries, ProductSeries, SourcePackage).

I am not sure how reasonable and practical for implementation something
like this is, but it'd finally provide a clear trail of where you most
likely came from.  It would not make it easy to eg. switch to Karmic
Serbian translations from Jaunty ones, but that'd be a problem for us to
solve in a different manner.

Cheers,
Danilo





Follow ups

References