Re: wgo url policy

[Jeff Waugh <jdub perkypants org>]

<quote who="Dave Neary">

> > Minimal redundancy
> > Avoid multiple URLs for a given page. Currently both http://gnome.org
> > and http://www.gnome.org exist. I suggest to forward all gnome.org
> > access to www.gnome.org. Are there any duplicate pages on wgo now?
> 
> These are not duplicate pages, they are aliases. gnome.org is an alias
> for www.gnome.org.

That's not what Gergely was pointing out, though the proximity of the two
points makes it easy to misunderstand his intent. First up, he's suggesting
that gnome.org should simply redirect to www.gnome.org, such that all Google
juice and so on points there, and we be very consistent in our use of the
domain name (a very good point - and now fixed, by the way). Additionally,
he was asking if there were duplicate pages (as opposed to domains) on the
site.

> > - I suggest no extensions to file names, this way resources can act as
> > containers
> > for example:
> > www.gnome.org/start and www.gnome.org/start/2.14
> > instead of
> > www.gnome.org/start.html and www.gnome.org/start/2.14 
> 
> I don't think this is really an issue. Direct linking to a html page is
> common, having one directory per page (which is what would result) is
> unwieldy, and (as you point out) .odf, .pdf, .jpg, etc - files have
> extensions, those extensions convey some information. I don't think we
> need a policy for this.

I do think this is an issue, and one that I have pushed as much as possible
on wgo as it stands today. It is significantly clearer and more future proof
to have a directory with an appropriately named index file in it than to be
referencing specific files all the time. I 100% support the *continuation*
of this policy. :-)

> > I could not yet decide what I think is the best URL scheme for I18N.
> 
> I think the best is no URL scheme for languages and use the browser
> preferences.

If you want to let people change the displayed language if the negotiated
one is incorrect or not desireable, you have to select some kind of URL
scheme. I don't think this needs to be fully defined ahead of time - the
scope for this will be defined by the technology we choose, though we can
certainly set some parameters. For instance: we can't use subdomains for
language codes, because some subdomains are already in use by local GNOME
groups; we probably shouldn't be screwing up our URLs by sticking language
codes in there; perhaps the query string approach is the best (can you use a
query string to override Apache content negotation already?).

- Jeff

-- 
linux.conf.au 2007: Sydney, Australia           http://lca2007.linux.org.au/
 
  We're kind of like Canada, only we hate ourselves more, and it's wetter
                             around the edges.