Michael Wechner wrote:
Jörn Nettingsmeier wrote:
well, in this case i disagree. i18n is great, but near the core, away
from the user, i18n gets messy and loses its importance.
do you mean the technology used or internationalization itself?
i18n itself. if done really correctly, it's a cool extra feature. i just
don't think the trade-off between a little more l10n and the extra
complication is worth it in things that are not really exposed to the user.
messy data structuring hurts the user in the long way (see the
examples i gave in my previous post).
URIs need to be systematic, and i would even prefer to have only *one*
canonical URI for whatever by default, multiple UR*L*s are always
compatibility hacks after the fact (and that's ok). but URIs should
*not* be localized by default.
why not?
they are the "book signatures" of the internet. when i go to a
library, the shelves are numbered the same, regardless of the language
the book is in. there is *one* dewey decimal system for catalogues in
all countries. it's abstract, and thus universal.
so, you mean everyone should use
urn:uuid:4243243243223423423423
instead
people/joern-nettingsmeier
well, it depends. people/joern-nettingsmeier is nicer to look at. but it
gives people the wrong idea. it's just as abstract as your uuid example.
thou shalt not tinker with system internals :)
>> granted, URIs are nowhere near as good and systematic, and the fact
>> that they contain letters and words can distract from the fact that
>> they are in reality very abstract identifiers.
now show me the code that will handle "mitarbeiter/jörn-nettingsmeier"
correctly in all cases, and yes, you will hate that "ö", because
suddenly the url can depend on the charset of your data backend, and
it's a world of pain. (been there, didn't touch it with a ten-foot-pole.)
something as fundamental as a resource identifier must not depend on
such things.
IMHO, URIs are becoming ever less important to the end-user, since
nobody ever types them anymore. so they move from "user-visible" to
"internal" and can be kept generic without loss of usability.
well, newspapers are starting to use them quite often to link
their print articles with further info.
Sure if we would have electronic paper ready, then it
would be different ...
for that, many papers indeed have an extra url space (numbers or
volatile textual urls).
they are ok for volatile stuff and as temporary resource *locators*. as
*identifiers*, they mostly suck, because they are never persistent enough.
OTOH, having a multi-dimensional uri space makes link management
harder by several orders of magnitude, and it's already non-trivial. i
think the added complexity will hurt users more than abstract,
non-localized urls. (besides, most of the huge international
corporations do not do it either, and nobody seems to care.)
well, I know a lot of people/companies who care ...
and as said before I would argue, that if people would have
the tools to actually manage such URL spaces, then they would
go full steam ahead (just as my comparison with the existence of
mobile phones and its consequences)
if it can be done correctly, fine. i just don't think it's worth the
effort. at the moment, there are more pressing things.
besides, url cleanliness has never been one of lenya's strong points
(it has favoured ease of implementation instead, to the point where
system internals that do not concern visitors at all are exposed via
the URLs).
that's why we want to improve it (for better as I believe)
i appreciate that, sorry if my choice of words sounded offending.
best,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
