nicht angemeldet
Gunnar Bittersmann
Auge
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
hallo,
ich arbeite gerade an einer webseite welche in 3 sprachen (englisch, deutsch, italienisch) vorliegen soll. der user kann zuerst auf der startseite seine sprache wählen, kann dies später aber auch noch in den unterseiten ändern, mittels 3 buttons.
der kunde will sich einen newsbereich (je sprache einer, also 3x) selbst updaten können.
WICHTIG: im optimalsten fall soll die seite auch auf mobilen endgeräten funktionieren -> mittels XHTML/CSS
nun hab ich 2 ansätze hierzu.
1. - mittels XSLT/XHTML/CSS:
das design wird mittels XHTML/CSS gemacht, für jede sprachversion gibt es XML's mit dem content, ich will content und design soweit wie möglich trennen. auch die hauptnavigation ist jeweils in einem eigenem XML file gespeichert. via PHP wird dann bei klick auf eine sprache eine varibable weitergereicht welche auf das jeweilig richtige XML pointet. der kunde kennt sich mit XML aus, so dass er sich seinen newsbereich selber updaten kann und das file mit FTP uploadet.
2. - mittels CMS Redaxo:
hat jmd erfahrung damit? es sollte angeblich dafür optimiert sein, mulitlanguale webseiten zu erstellen und der kunde könnte sich seinen newsbereich noch einfacher updaten.
erzeugt es validen code, möglichst schlank und tablefrei? wie flexibel bin ich mit der einbindung meines eigenen designs (XHTML/CSS) und javascripts?
was haltet ihr von den ansätzen? hättet iht noch weitere vorschläge hierzu oder einen weiteren möglichen ansatz?
danke für antworten
peter
Hello out there!
der user kann zuerst auf der startseite seine sprache wählen,
Nö, das ist eine überflüssige Belastung des Nutzers. Der Server kann gleich die Sprachversion ausliefern, die den Browsereinstellungen des Nutzers entgegenkommt.
"Language content negotiation" ist dein Suchbegriff. Auch unter http://www.w3.org/International/ gibt es gute Artikel dazu.
kann dies später aber auch noch in den unterseiten ändern,
Ja, die Möglichkeit sollte vorhanden sein.
im optimalsten fall
Äh, es geht noch optimaler als „optimal“? ;-)
See ya up the road,
Gunnar
Hallo
der user kann zuerst auf der startseite seine sprache wählen,
Nö, das ist eine überflüssige Belastung des Nutzers. Der Server kann gleich die Sprachversion ausliefern, die den Browsereinstellungen des Nutzers entgegenkommt.
kann dies später aber auch noch in den unterseiten ändern,
Ja, die Möglichkeit sollte vorhanden sein.
Dies aber auch auf der Startseite (weil du so deutlich "Nö" sagtest ;-)), außer die Startseite dient ausschließlich der Auswahl der Sprache. Dann sollte sie, gemäß deiner Einlassung am besten gleich weggelassen werden.
Es gibt ja schließlich auch den Fall des Seitenbesuchers, der nicht mit einem Browser in _seiner_ bevorzugten Sprache unterwegens ist.
z.B. der Touri im Internetcafé
Tschö, Auge
Hello out there!
der user kann zuerst auf der startseite seine sprache wählen,
[schnipp]
Ja, die Möglichkeit sollte vorhanden sein.
Dies aber auch auf der Startseite (weil du so deutlich "Nö" sagtest ;-)), außer die Startseite dient ausschließlich der Auswahl der Sprache.
So hatte ich das Wörtchen „zuerst“ im OP gedeutet.
Dann sollte sie, gemäß deiner Einlassung am besten gleich weggelassen werden.
Darauf wollte ich hinaus.
Es gibt ja schließlich auch den Fall des Seitenbesuchers, der nicht mit einem Browser in _seiner_ bevorzugten Sprache unterwegens ist.
Ja, deshalb plädiere ich ja auch immer für die Sprachauswahlmöglichkeit durch den Nutzer (Linktitel in der Zielsprache, keine Flaggen); s.a. den im Thread bereits verlinkten Artikel http://www.w3.org/International/questions/qa-when-lang-neg
See ya up the road,
Gunnar
Hallo
Es gibt ja schließlich auch den Fall des Seitenbesuchers, der nicht mit einem Browser in _seiner_ bevorzugten Sprache unterwegens ist.
Ja, deshalb plädiere ich ja auch immer für die Sprachauswahlmöglichkeit durch den Nutzer (Linktitel in der Zielsprache, keine Flaggen);
Jupp, wobei ich zur Flaggenfrage eine andere Antwort habe. Es kann tausendmal falsch sein, die Flagge eines bestimmten Staates zum Symbol einer Sprache zu machen, da eine Sprache oftmals nicht nur in einem Land gesprochen wird. Dennoch ist das System bekannt und jeder (Ausnahmen mögen die Regel bestätigen) findet sich darin zurecht.
Um es etwas "blumiger" zu formulieren: Auch wenn der Yankee noch tausend Ladungen britischen Tees in's Meer kippt, er wird den mit dem verhassten Union Jack verzierten Link benutzen, um ein englischsprachiges Angebot einer Website nutzen zu können.
Tschö, Auge
- mittels CMS Redaxo:
hat jmd erfahrung damit? es sollte angeblich dafür optimiert sein, mulitlanguale webseiten zu erstellen und der kunde könnte sich seinen newsbereich noch einfacher updaten.
Redaxo kann mehrsprachige Websites sehr gut bedienen, das ist richtig. Es funktioniert so, dass du beliebige Sprachen anlegen kannst, die automatisch die komplette Seitenstruktur erhalten und im Backend wie Karteireiter ausgewählt werden. Du schaltest also beim Befüllen der Inhalte einfach hin und her. Hat eine Sprache noch keinen Inhalt vom Redakteur bekommen, ist ein Artikel und ein Verzeichnis zwar angelegt (s.o.), ist aber leer und hat den Status »offline«. Zudem ist es so, dass beim Übernehmen der Struktur natürlich auch die Namen - und damit die URLs - der Standardsprache übernommen werden: solange der Redakteur also nichts ändert, ergeben sich URLs wie /en/hallo-welt/. Möchte man vollständig und sinnvoll übersetzen, ändert man also auch die Verzeichnis- und Artikelnamen und erhält danach /en/hello-world/.
Mehrsprachigkeit ist aber aus Usabilitysicht ein sehr komplexes Thema, denn man kann sowohl die Benutzerführung weiter optimieren als auch den Umgang der Redakteure mit dem System. Ein paar grobe Denkanstöße:
Sprachfolge: ist ein Artikel in Landessprache nicht verfügbar, sollte eine sinnvolle Sprachfolge existieren. So sollte z.B. der italienische Nutzer zuerst den englischen Text erhalten, wenn verfügbar, und danach den deutschen Text. Natürlich immer gepaart mit dem Hinweis darauf, dass die Landessprache leider nicht verfügbar ist, und an wen man sich zwecks Übersetzung oder weiterer Information wenden kann.
Contentpflege: allgemeingültige Inhalte und Basisstrukturen eines Artikels sollten sprachweit verfügbar sein, ohne dass der Redakteur sie explizit angeben muss. Beispiel Fotos oder andere Medien: einmal in der Standardsprache ausgewählt/eingesetzt sollte sie automatisch auch in anderen Sprachen verfügbar machen. Ist das nicht der Fall, muss der Redakteur z.B. alle 93 Fotos eine Bildergalerie in 5 Sprachen immer wieder aufs Neue einsetzen.
erzeugt es validen code, möglichst schlank und tablefrei? wie flexibel bin ich mit der einbindung meines eigenen designs (XHTML/CSS) und javascripts?
Redaxo kann aufgrund seiner Struktur alles das, was du auch von Hand auf einer statischen Website machen kannst. Manches kann dabei vielleicht etwas Anpassungsaufwand erfordern, aber grundsätzlich geht alles.
An dieser Stelle aber eine Warnung: ein System wie Redaxo anzupassen ist nicht einfach und benötigt Erfahrung. Zudem ist es selten »mal eben« gemacht, sondern kann in einen echten Haufen Arbeit ausarten. Die oben genannten Features zur Sprachfolge und Contentpflege zum Beispiel sind ein Heidenaufwand, den man auch nicht schönreden kann :)
was haltet ihr von den ansätzen? hättet iht noch weitere vorschläge hierzu oder einen weiteren möglichen ansatz?
Viel. Ich halte Redaxo für das mit Abstand sinnvollste CMS da draußen :)
Viele Grüße!
_ds
Hello out there!
[…] ergeben sich URLs wie /en/hallo-welt/. Möchte man vollständig und sinnvoll übersetzen, ändert man also auch die Verzeichnis- und Artikelnamen und erhält danach /en/hello-world/.
IMHO sollten verschiedene Sprachfassungen mit identischem Inhalt unter einunddemselben URI verfügbar sein; per language content negotiation erhält jeder Nutzer die seinen Browsereinstellungen entsprechende Fassung.
Also /hallo-welt oder /hello-world oder beides, denn für den Nutzer sind Pfadbezeichnungen in seiner Sprache natürlich besser.
Aus anderer Sicht ein Dilemma: verschiedene URIs für dieselbe Ressource.
- Sprachfolge: ist ein Artikel in Landessprache nicht verfügbar, sollte eine sinnvolle Sprachfolge existieren. So sollte z.B. der italienische Nutzer zuerst den englischen Text erhalten, wenn verfügbar, und danach den deutschen Text.
Einspruch: Ein Nutzer, dessen Browsereinstellungen die bevorzugten Sprachen in der Reihenfolge it,de(,en) angeben, sollte bei Nichtvorhandensein einer italienischen Fassung die deutsche präsentiert bekommen.
See ya up the road,
Gunnar
IMHO sollten verschiedene Sprachfassungen mit identischem Inhalt unter einunddemselben URI verfügbar sein; per language content negotiation erhält jeder Nutzer die seinen Browsereinstellungen entsprechende Fassung.
Finde ich nicht gut, denn gleiche Inhalte in unterschiedlichen Sprachen sind keine »identischen« Inhalte. Google würde deinen mehrsprachigen Webauftritt vollständig auf Englisch abgrasen.
Einspruch: Ein Nutzer, dessen Browsereinstellungen die bevorzugten Sprachen in der Reihenfolge it,de(,en) angeben, sollte bei Nichtvorhandensein einer italienischen Fassung die deutsche präsentiert bekommen.
Stattgegeben :) Allerdings spricht die Welt vermutlich aus Browsersicht maximal zwei Sprachen: ich würde davon ausgehen, dass der Großteil der Nutzer seinen Browser nicht mit einer Sprachfolge ausstattet, sondern allenfalls seine Hauptspache angibt.
Aber man kann es ja prüfen, damit hast du vollkommen recht, und dann der evtl vorhandenen Sprachfolge des Benutzers natürlich Vorrang vor der vom Websitebetreiber festgelegten Sprachfolge geben.
Viele Grüße!
_ds
Hello out there!
IMHO sollten verschiedene Sprachfassungen mit identischem Inhalt unter einunddemselben URI verfügbar sein; per language content negotiation erhält jeder Nutzer die seinen Browsereinstellungen entsprechende Fassung.
Finde ich nicht gut, denn gleiche Inhalte in unterschiedlichen Sprachen sind keine »identischen« Inhalte.
OK, ich formuliere neu: IMHO sollten verschiedene Sprachfassungen mit gleichem Inhalt unter einunddemselben URI verfügbar sein.
Google würde deinen mehrsprachigen Webauftritt vollständig auf Englisch abgrasen.
Und auch die anderen Sprachfassungen.
Jede Sprachfassung hat neben dem generischen auch ihren eigenen URI und jede Sprachfassung ist von jeder anderen verlinkt; sonst wäre ja die Auswahl durch den Nutzer jenseits von language content negotiation nicht möglich. [</archiv/2006/4/t127369/#m822969>]
ich würde davon ausgehen, dass der Großteil der Nutzer seinen Browser nicht mit einer Sprachfolge ausstattet
Das ist in der Tat ein Problem. Browserhersteller verstecken wichtige Funktionen in unübersichtlichen Menüs, so dass Nutzer die Funktionalität ihres Browsers nicht voll ausnutzen.
Das sollte aber nicht Grund sein, den Nutzern, die hinter die Möglichkeiten ihres Browsers gestiegen sind, die Nuztung der Möglichkeiten zu verwehren.
See ya up the road,
Gunnar
Google würde deinen mehrsprachigen Webauftritt vollständig auf Englisch abgrasen.
Und auch die anderen Sprachfassungen.
Aber nur dann, wenn jede Sprachfassung eine eigene URL hat (Variante 2, die du oben beschrieben hattest), die explizt und unabhängig von der Browserkonfiguration diese Sprache ausgibt.
Und wenn das der Fall ist, verstehe ich die Motivation, den Nutzen und den Aufwand dafür nicht, unique URLs für alle Sprachen auszuliefern?
Viele Grüße!
_ds
Hi,
Und wenn das der Fall ist, verstehe ich die Motivation, den Nutzen und den Aufwand dafür nicht, unique URLs für alle Sprachen auszuliefern?
eine Motivation ist, nicht nur den Inhalt, sondern auch die URL (besser) lesbar zu machen. Ein englischsprachiger Besucher wird sich unter ?impressum vielleicht genauso wenig vorstellen können wie unter ?site=42, unter ?legal_notice schon eher.
Ein weiterer Grund - für mich jedenfalls - ist, dass ich ohne zusätzliche Angaben wie weitere Sprach-Parameter oder -Verzeichnisangaben auskomme.
freundliche Grüße
Ingo
eine Motivation ist, nicht nur den Inhalt, sondern auch die URL (besser) lesbar zu machen.
Das sehe ich genauso (siehe auch mein erstes Posting in diesem Zweig), das kam vielleicht falsch rüber.
Viele Grüße!
_ds
Hello out there!
Aber nur dann, wenn jede Sprachfassung eine eigene URL hat (Variante 2, die du oben beschrieben hattest), die explizt und unabhängig von der Browserkonfiguration diese Sprache ausgibt.
Variante 2?? Was wäre denn Variante 1? Ausschließlich generische URIs und language negotiation als alleinige Sprachauswahl? Davon war nicht die Rede, hoffe ich.
Und wenn das der Fall ist, verstehe ich die Motivation, den Nutzen und den Aufwand dafür nicht, unique URLs für alle Sprachen auszuliefern?
Wenn du anderen einen generischen URI einer Ressource mit language negotiation verlinkst oder auf anderem Wege mitteilst, musst du dir keine Gedanken darüber machen, welche Sprachversion der Nutzer gerne lesen möchte. Eventuell weißt du es auch gar nicht.
“Language negotiation is good because, if Jaap emails a link inside www.example.be to Pierre, Pierre will be happy to get the French version, even though Jaap read the Flemish one.” [http://www.w3.org/International/questions/qa-when-lang-neg]
Der Artikel selbst ist ein Beispiel dafür: Hinter dem URI stecken die englische, die französische und die polnische Version. Da ich kein Französisch kann und Englisch in meinen Browsereinstellungen vor Polnisch steht, bekomme ich den Artikel auf Englisch zu lesen. Jeena mag seinen Browser so konfiguriert haben, dass er den Artikel auf Polnisch ausgeliefert bekäme. Wir wissen’s nicht; müssen wir auch nicht. Es kann uns egal sein, ob Jeena Polnisch oder Englisch oder Französisch bevorzugt. Für ihn ist der Artikel in der ihm genehmen Sprache verlinkt. Dafür sind generische URIs gut.
See ya up the road,
Gunnar
Variante 2?? Was wäre denn Variante 1? Ausschließlich generische URIs und language negotiation als alleinige Sprachauswahl? Davon war nicht die Rede, hoffe ich.
Das, meinte ich, ja. Aber okay, dann ist also klar, dass es zwingend unique URLs für jede Sprachvariante geben muss.
Wenn du anderen einen generischen URI einer Ressource mit language negotiation verlinkst oder auf anderem Wege mitteilst, musst du dir keine Gedanken darüber machen, welche Sprachversion der Nutzer gerne lesen möchte. Eventuell weißt du es auch gar nicht.
Okay, das finde ich gut und sinnvoll. Funktioniert ja z.B. auch bei php.net sehr gut.
Aber mir ist noch nicht so recht klar, wie du sowas innerhalb eines CMS wie Redaxo umsetzen möchtest:
1. URLs: ein Produkt aus einem Produktkatalog eines imaginären Unternehmens hat die URLs /de/produkte/auto/ und /en/products/car/ ..wie soll die generische URL für beide aussehen? Wie frisst Google die drei(?) URLs? Und wie geht der Benutzer damit um: wir er standardmäßig zuerst auf die generische geführt, und erst wenn er aktiv wechselt, landet er auf der URL für die Sprachvariante?
2. Inhalt: Content Negotiation funktioniert ganz oder gar nicht, nehme ich an, jedoch nicht für Teilbereiche einer Seite? Ich bin davon ausgegangen, als ich anfangs von einem »Artikel« sprach, dass es sich dabei nur um den Hauptinhalt handelt, ähnlich eines Posts innerhalb eines Blogs also. Ich würde in einer Umgebung wie Redaxo z.B. die Sprachfolge für alle Teilbereiche der Seite prüfen, also auch die Navigation oder andere Seitenelemente. Denn beim Einpflegen von Inhalten wird die Grundstruktur für gewöhnlich sehr schnell übernommen, während Hauptinhalte natürlich mehr Aufwand erfordern. Eine Seite innerhalb des Webangebots könnte dadurch aus einer italienischen Navigation bestehen und eine italienische Sidebar haben, allerdings den Hauptinhalt auf Englisch anzeigen, weil er auf Italienisch noch nicht verfügbar ist. So geschehen bei einem Projekt, das wir mit Redaxo wie beschrieben betreuen.
Wie sähe die Situation aus, wenn man nach deiner Methode vorginge? Und vor allem: wie ließe sich das in einem CMS umsetzen?
Blödes Timing: ich bin jetzt leider ein kleines Weilchen offline, so dass der Thread vermutlich im Archiv ist, wenn ich ihn wieder lese. Aber mich würde deine Antwort brennend interessieren, und vielleicht können wir ja später einen neuen Thread eröffnen, um Unklares nochmal zu besprechen..
Viele Grüße!
_ds
Hallo,
[Bei generischen URIs] musst du dir keine Gedanken darüber machen, welche Sprachversion der Nutzer gerne lesen möchte. Eventuell weißt du es auch gar nicht.
Okay, das finde ich gut und sinnvoll. Funktioniert ja z.B. auch bei php.net sehr gut.
schlechtes Beispiel: Gerade bei php.net gibt es einiges Durcheinander mit den Sprachfassungen. Meine Browser sind alle auf Englisch als bevorzugte Sprache eingestellt, aber bei php.net lande ich nach einigen Klicks immer wieder scheinbar willkürlich auf einer der deutschen Seiten - sogar wenn ich ausdrücklich auf /manual/en/... unterwegs bin. Ganz plötzlich, wenn ich nicht damit rechne, führt mich irgendein Link wieder auf /manual/de/...
So long,
Martin
Hello out there!
Aber mir ist noch nicht so recht klar, wie du sowas innerhalb eines CMS wie Redaxo umsetzen möchtest:
Vorneweg: Ich habe vom Umgang mit CMS nicht wirklich viel Ahnung.
- URLs: ein Produkt aus einem Produktkatalog eines imaginären Unternehmens hat die URLs /de/produkte/auto/ und /en/products/car/
Warum? Warum nicht 'http://example.com/produkte/auto' und 'http://example.com/products/car'? Dem Konzept der menschenlesbaren URIs laufen die Pfadteile 'de/' und 'en/' zuwider.
wie soll die generische URL für beide aussehen?
'http://example.com/produkte/auto' und 'http://example.com/products/car'.
Könnte (auf einem Server unter UNIX/Linux) so realisiert werden, dass 'produkte' ein symbolischer Link zu 'products' ist (oder andersrum), entsprechend 'auto' zu 'car'.
Oder serverseitige Weiterleitung/Alias.
Im Verzeichnis 'car' = 'auto' gibt es 'index.en.html' und 'index.de.html'.
Wie frisst Google die drei(?) URLs?
Hm, da wäre noch eniges Gehirnschmalz reinzustecken: es sollten bspw. 'http://example.com/produkte/auto/index.de.html' und 'http://example.com/products/car/index.en.html' indiziert werden, nicht aber 'http://example.com/produkte/auto/index.en.html' und 'http://example.com/products/car/index.de.html'.
Und wie geht der Benutzer damit um: wir er standardmäßig zuerst auf die generische geführt, und erst wenn er aktiv wechselt, landet er auf der URL für die Sprachvariante?
Ja, genau.
- Inhalt: Content Negotiation funktioniert ganz oder gar nicht, nehme ich an, jedoch nicht für Teilbereiche einer Seite?
Doch, content negotiation funktioniert für jeden einzelnen URI.
Probleme damit sind im Artikel “FAQ: When to use language negotiation” unter Navigation angesprochen.
Und vor allem: wie ließe sich das in einem CMS umsetzen?
Wie angedeutet, kann ich dazu nicht viel sagen.
Blödes Timing: ich bin jetzt leider ein kleines Weilchen offline
Hättest du das nicht geschrieben, um dann doch noch ein kleines Weilchen zu bleiben, hätte ich mich mit meiner Antwort mehr beeilt.
und vielleicht können wir ja später einen neuen Thread eröffnen, um Unklares nochmal zu besprechen..
Oder uns mal zum Fachsimpeln treffen.
See ya up the road,
Gunnar
Moin!
Wenn du anderen einen generischen URI einer Ressource mit language negotiation verlinkst oder auf anderem Wege mitteilst, musst du dir keine Gedanken darüber machen, welche Sprachversion der Nutzer gerne lesen möchte. Eventuell weißt du es auch gar nicht.
“Language negotiation is good because, if Jaap emails a link inside www.example.be to Pierre, Pierre will be happy to get the French version, even though Jaap read the Flemish one.” [http://www.w3.org/International/questions/qa-when-lang-neg]
Was ist, wenn Jaap explizit den Flämischen Text verlinken wollte, weil sich darin ein sprachlicher Faux-Pas wiederfindet, oder sonst eine Nettigkeit, die sich in der französischen Variante nicht findet. Oder wenn er einen Fehler in dieser Seite melden will?
Was ist, wenn Pierre hinreichend gut Flämisch spricht, um das ggf. auch zu verstehen, was Jaap ihm damit sagen wollte, er aber trotzdem Französisch als bevorzugte Sprache eingestellt hat (und als zweite Sprache dann vielleicht Flämisch)?
- Sven Rautenberg
Hello out there!
Was ist, wenn Jaap explizit den Flämischen Text verlinken wollte
Dann hätte er es getan. Die flämische Versiion ist ja über ihren eigenen URI ansprechbar.
Was ist, wenn Pierre hinreichend gut Flämisch spricht […], er aber trotzdem Französisch als bevorzugte Sprache eingestellt hat […]?
Dann findet er auf der französischen Seite den Link zur flämischen.
See ya up the road,
Gunnar
Hi,
Also /hallo-welt oder /hello-world oder beides, denn für den Nutzer sind Pfadbezeichnungen in seiner Sprache natürlich besser.
Aus anderer Sicht ein Dilemma: verschiedene URIs für dieselbe Ressource.
das sehe ich nicht so. Es wird nicht dieselbe Ressource präsentiert und auch nicht derselbe Inhalt - sondern "nur" der gleiche in einer anderen Sprache. Das rechtfertigt auch eine andere URL ín eben dieser Sprache. Warum sollte, wenn sich der Linktext von "Kontakt" nach "contact" ändert, in der URL "kontakt" stehen bleiben?
freundliche Grüße
Ingo
IMHO sollten verschiedene Sprachfassungen mit identischem Inhalt unter einunddemselben URI verfügbar sein;
Das halte ich für absolut unsinnig. URIs enthalten bei artgerechter Haltung wichtige Information, die so verloren geht. Wie willst du URIs denn sinnvoll gestalten? Mit Esperanto?
per language content negotiation erhält jeder Nutzer die seinen Browsereinstellungen entsprechende Fassung.
Allenfalls auf der Startseite oder wenn übergeordnete Verzeichnisse direkt aufgerufen werden. Selbst dann hielte ich eine Weiterleitung auf die im Browser eingestellte Sprachversion für notwendig. Aus /chapter kann dann gerne /de/kapitel (und somit indiziert) werden.
Also /hallo-welt oder /hello-world oder beides, denn für den Nutzer sind Pfadbezeichnungen in seiner Sprache natürlich besser.
Und unter /hallo-welt erhalte ich dann englischen Inhalt, weil mein Browser so eingestellt ist?
Aus anderer Sicht ein Dilemma: verschiedene URIs für dieselbe Ressource.
Duplicate Content ist unangenehm, aber Half Content ist m.E. schlimmer. Folgt man deiner Empfehlung, ist viel vom Inhalt überhaupt nicht mehr erreichbar.
Einspruch: Ein Nutzer, dessen Browsereinstellungen die bevorzugten Sprachen in der Reihenfolge it,de(,en) angeben, sollte bei Nichtvorhandensein einer italienischen Fassung die deutsche präsentiert bekommen.
Ja. Und ab diesem Zeitpunkt muss er die Wahl haben, nicht der Browser (lies: Server).
Roland
Hello out there!
IMHO sollten verschiedene Sprachfassungen mit identischem Inhalt unter einunddemselben URI verfügbar sein;
Das halte ich für absolut unsinnig.
Auch nach Lesen dieses Postings von mir noch?
URIs enthalten bei artgerechter Haltung wichtige Information, die so verloren geht.
Die da wäre?
Wie willst du URIs denn sinnvoll gestalten? Mit Esperanto?
Misst du der Lesbarkeit von URIs für Menschen zu viel Bedeutung zu? URIs sind für Maschinen; Links sind für Menschen.
per language content negotiation erhält jeder Nutzer die seinen Browsereinstellungen entsprechende Fassung.
Allenfalls auf der Startseite
Nö, auf jeder Seite. Sonst würden ja deep links in die Website einen Nutzer evtl. zur falschen Sprachvariante führen.
Folgt man deiner Empfehlung, ist viel vom Inhalt überhaupt nicht mehr erreichbar.
Jetzt seh ich, dass du tatsächlich meine anderen Postings in diesem Thread noch nicht gelesen hast. Denn ...
Ja. Und ab diesem Zeitpunkt muss er die Wahl haben, nicht der Browser (lies: Server).
... das sag ich doch.
See ya up the road,
Gunnar
Hell in here too!
[slurp]
Das halte ich für absolut unsinnig.
Auch nach Lesen dieses Postings von mir noch?
Ich ging frohgemut und grob fahrlässig davon aus, du würdest keine Erstlingsantworten verfassen, die du im weiteren Verlauf zurechtzubiegen hast. Nun muss ich deinen Stammposterbonus überdenken, ehm.
URIs enthalten bei artgerechter Haltung wichtige Information, die so verloren geht.
Die da wäre? […] Misst du der Lesbarkeit von URIs für Menschen zu viel Bedeutung zu? URIs sind für Maschinen; Links sind für Menschen.
URIs sind für Menschen. Sie sind eine erste Vorabinformation über den zu erwartenden Inhalt und die letzte Rettung, wenn andere Navigationsmechanismen versagt haben. Im Idealfall sind sie ähnlich der Struktur eines Breadcrumb-Trails angelegt und gleichzeitig ein Mini-Exzerpt des Inhalts. URIs sind wichtig, nicht nur für Maschinen.
language content negotiation
Allenfalls auf der Startseite
Nö, auf jeder Seite. Sonst würden ja deep links in die Website einen Nutzer evtl. zur falschen Sprachvariante führen.
Warum? Dort erwarten ihn gar bunte Fähnchen. >;)
[…] das sag ich doch.
Jaja.
Roland
Hello out there!
Ich ging frohgemut und grob fahrlässig davon aus, […]
:-)
[…] du würdest keine Erstlingsantworten verfassen, die du im weiteren Verlauf zurechtzubiegen hast.
Sagen wir „ergänzen“.
Nun muss ich deinen Stammposterbonus überdenken, ehm.
Ehm, ich dachte schon, ich hätte keinen.
URIs sind für Maschinen; Links sind für Menschen.
URIs sind für Menschen.
Welcher Mensch braucht sowas wie "http://" in einem URI?
URIs sind (in erster Linie) für Maschinen, damit eine solche (bspw. ein Nutzerprogramm wie ein Browser) eine Ressource im WWW finden kann.
Menschen finden Informationen im Web hauptsächlich durch das Folgen von Links.
Dass URIs dennoch auch für Menschen gut lesbar sein sollten, ist kein Widerspruch dazu.
Im Idealfall sind sie ähnlich der Struktur eines Breadcrumb-Trails angelegt
Nicht unbedingt. Die Organisation der Dateistruktur auf einem Webserver (woraus sich im einfachsten Fall die URIs ergeben) und die Organisation der Navigation durch die Website für den Nutzer sind verschiedene Dinge und können völlig getrennt geplant werden.
So ist eine flache Dateistruktur (alle Webseiten-Dateien in einem Verzeichnis) denkbar, wobei die Navigation dennoch tief ist: Kapitel, Unterkapitel, ... Oder andersrum: verschachtelte Verzeichnisse (URIs wie http://example.net/foo/bar/baz/quz), dennoch flache Navigation (alle Links auf der Startseite).
Da Konzept der strengen Hierarchie (und damit von Breadcrumbs) ist im Web problematisch; es widerspricht ja dem Gedanken von Hypertext, wo „viele Wege nach Rom führen“.
See ya up the road,
Gunnar
Stammposterbonus
Ehm, ich dachte schon, ich hätte keinen.
Und ich dachte, du könntest mit solch komplexen Zahlen umgehen. ;-)
URIs sind für Menschen.
Welcher Mensch braucht sowas wie "http://" in einem URI?
Keiner, weswegen Browser es bei Bedarf auch ergänzen.
URIs sind (in erster Linie) für Maschinen, damit eine solche (bspw. ein Nutzerprogramm wie ein Browser) eine Ressource im WWW finden kann.
In erster Linie, ja. Aus Sicht des Nur-Nutzers ist der technische Background aber relativ egal, solange es funzt™.
Menschen finden Informationen im Web hauptsächlich durch das Folgen von Links.
Dass URIs dennoch auch für Menschen gut lesbar sein sollten, ist kein Widerspruch dazu.
Ab hier produzieren wir noch ein bisschen Spliss.
Im Idealfall sind sie ähnlich der Struktur eines Breadcrumb-Trails angelegt
Nicht unbedingt. Die Organisation der Dateistruktur auf einem Webserver (woraus sich im einfachsten Fall die URIs ergeben) und die Organisation der Navigation durch die Website für den Nutzer sind verschiedene Dinge und können völlig getrennt geplant werden.
Ich sehe da keinen Widerspruch. Dass eine Ähnlichkeit von URIs und Breadcrumb Trails sinnvoll ist heißt ja für keinen der beiden Teile, die Dateistruktur abbilden zu müssen.
flache Dateistruktur (alle Webseiten-Dateien in einem Verzeichnis)
Wie bei tf.htm, tfb.htm, tfbe.htm usw. in SELFHTML 7. Jetzt werde ich gleich historisch.
(URIs wie http://example.net/foo/bar/baz/quz), dennoch flache Navigation (alle Links auf der Startseite).
Ach, darauf willst du also hinaus. Mir ging es weniger um Navigation im engeren Sinne als um die Transparenz des Standorts.
Da Konzept der strengen Hierarchie (und damit von Breadcrumbs) ist im Web problematisch; es widerspricht ja dem Gedanken von Hypertext, wo „viele Wege nach Rom führen“.
Breadcrumb-Trails sind wie schon oben erwähnt keine Wegweiser sondern ermöglichen die Standortbestimmung. Wie eben URIs auch. Mit Navigation haben sie nur insofern zu tun, als dass sie den schnellen Rückweg ermöglichen. Da will ich weder englischsprachige URIs mit deutschsprachigen Inhalten noch eine ungefragte Umleitung, weswegen URIs für mich eindeutig sein müssen. Jedem Inhalt in jeder Sprache gebührt ein zugehöriger URI.
Roland
Der Martin