launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Mon, 2009-08-17 at 15:57 +0200, Danilo Šegan wrote:
> 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

Right, I meant that for app-specific pages that don't clash with an
existing one on the mainsite.

> 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

This change has landed recently, so from now on whenever you use
person/fmt:link you'll get a link to the mainsite.

> 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).

That's what I'm aiming for.  The solution I currently have uses named
adapters, with the Hierarchy view iterating over the existing
breadcrumbs (starting at the end) and looking for an IBreadcrumbBuilder
adapter with the vhost's name for the breadcrumb's context. When one is
found, we build an extra breadcrumb (using the builder) and insert it
after the current position. So, in the examples above, IPerson and
IDistroSeries would have an IBreadcrumbBuilder adapter with
name="translations" that would build a breadcrumb for the translations
facet of the person/distroseries.

That seems to accommodate all the examples at
https://wiki.canonical.com/Launchpad/UI/Navigation and the others I
could think of.

The problem with any generic solution, though, is that some links have
to point to the mainsite regardless of the host we're currently on, and
if you look at the examples on the page above you'll see it's not easy
to derive some set of rules for what are the items that must explicitly
point to the mainsite.  That's why I considered having them all link to
the mainsite.

> 
> 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
> 
> 
-- 
Guilherme Salgado <salgado@xxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part