wgo url policy
- From: Gergely Nagy <greg gnome hu>
- To: marketing list <marketing-list gnome org>
- Subject: wgo url policy
- Date: Thu, 13 Jul 2006 14:55:19 +0200
First of all, great work guys,
Quim's list of goals, Sigurd's Policy page and Christian's Localization
document are Excellent! (all in live.gnome.org)
I would like to start discussion on our URL policies.
Requirements
- persistent
- support site partitioning
- minimal redundancy
- friendly urls
- own url for each "resource"
- no collisions
- i18n content
Persistent
We must design our URL name spaces carefully now, so they don't change
with every site update.
Support site partitioning
DNS subdomains and folder hierarchy allows content partitioning. We must
decide what goes into its own domain, and what goes in subdirectories.
For now, our scope is www.gnome.org but perhaps need some subdomains
already? Waiting for partitioning draft.
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?
Friendly URLs
The basic idea is simple, but it will be hard to come up with the final
policy. I think the current wgo system got it quite right, but some
issues remain.
- 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
problem: multiple formats, e.g. how do I get PDF representation?
maybe use extensions for alternate formats?
e.g. www.gnome.org/whatever and www.gnome.org/whatever.pdf ?
- let's keep URLs lowercase?
does such a policy make sense? it's purely cosmetic, but can suggest
consistency across gnome websites, if applied throughout
- could be problem with WikiNames - perhaps they will be exceptions?
Own URL for each resource
we have to think carefully what are our resources, and provide a URL to
each.
For example, a news section can have several resources aggregating the
news, e.g. /news for the latest, /news/2006/08 for archives, they
_could_ show the same content at a given time, but they are different
resources. Let's see what content partitioning comes up with.
No collisions
A URL should always point to the same resource. Once we define a URL, we
should not change it's meaning. Say, we create a page, remove it after
it expires, and then later create another one with the same URL - BAD.
I18N
Several issues here
There are some great suggestions for serving multiple languages at:
http://live.gnome.org/GnomeWeb/Localization
I suggest the following, in order of relevance:
- The strongest is direct URL access, requiring each translated page to
have it's own URL.
- If the "Generic" language page is accessed, a cookie is checked.
- If no cookie is set, the browser settings are applied
- If all fails, display page in original language
Apart from being able to refer to a specific language (e.g. in
translation bug report), URL can act as a fallback where no cookies are
supported, and browser settings are not changeable (kiosk?)
I could not yet decide what I think is the best URL scheme for I18N.
Ideas:
www.gnome.org/x/y/z?lang=LANG
www.gnome.org/LANG/x/y/z
www.gnome.org/x/y/z.LANG
the last one has a problem though:
www.gnome.org/x.LANG
www.gnome.org/x.LANG/y.LANG or www.gnome.org/x/y.LANG ?
Suggestions?
Internationalized URLs
It might seem strange to see a translated page under an untranslated
URL. Since we strive for user-friendly URLs, which can be easily
remembered and typed in, this will be a deficiency for non-english
speaking visitors. I guess this is unavoidable for wgo multilanguage
pages... Any thoughts on this?
cheers,
Greg
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]