[Ben]

Hallo,
ich möchte mir in meiner Anwendung die Möglichkeit offen halten mittel- bis langfristig auch mehrsprachige Inhalte zu verwalten.

Nun stoße ich auf ein Problem bzw. eine Fragestellung, wo mir Lösung bzw. Beantwortung nicht ganz klar ist.

Standardmäßig hätte ich die Inhalte jetzt z.B. über domain.xy/category/content-identifier bezogen. Hier fehlt aber nun natürlich die Angabe der Sprache, in der der Inhalt dargestellt werden soll. Es gibt nun die Möglichkeit standardmäßig keinen "identifier" zu setzen, der dann der Standardsprache, in meinem Fall "deutsch", entspricht. Alternativ müsste auch standardmäßig dieser Parameter gesetzt sein.

Desweiteren ist in diesem Zusammenhang die Frage anzuschließen, wo dieser Parameter übergeben werden sollte. Den Weg über eine Subdomain möchte ich ehrlich gesagt ausschließen, auch wenn es der einfachste wäre. Nichstdestotrotz suche ich alternative Wege.

Optimal fände ich dabei irgendwas in dieser Art:
domain.xy/de/category/content-identifier

Höre gerne Meinungen und Vorschläge.

Grüße, Ben.


PS:
Habe dieses Forum gewählt, weil es mir auf den Sack geht, dass so Beiträge standardmäßig in der Plauderecke angesiedelt werden müssen, weil wir sonst kein passendes Forum haben.

[$traight-$hoota]

Ich würde die Sprache eher nicht so in den URL path packen, weil es eigentlich es keine komponente ist, die den inhalt/die webseite lokalisiert sondern die art der darstellung beeinflusst. deshalb sollte die sprache eher als parameter zur darstellung übergeben werden bzw. im normalfall in der session und/oder als cookie gespeichert werden und nur für änderungen der sprache explizit im url enthalten sein.

[Ben]

Durchaus ein guter Einwand. Allerdings finde ich schon, dass dieser Parameter en Inhalt der Seite beschreibt. Er gibt an, ob es sich um einen Inhalt in Sprache x oder y oder ... handelt.

In meinem Beispiel hätte ich dann so etwas
domain.xy/en/news
domain.xy/de/news

Wäre natürlich perfekt, wenn es dann auch "nachrichten" anstatt "news" heißen würde, aber das ist etwas, wo ich derzeit überhaupt keinen Anhaltspunkt hätte, wie man so etwas realisiert.
Sollte es da eine gute Idee zu geben, so wäre natürlich dein Vorschlag fein, weil man dann einfach so etwas hätte
domain.xy/news/
domain.xy/nachrichten/

Wobei es sich dann z.B. bei Kategorien überschneiden würde, die in z.B. deutsch wie englisch gleich heißen würden ... Beispiel: FAQ.


Nachtrag:
Ich erweitere meine Fragestellung.

Ich würde es gerne so haben, dass ich Inhalte übersetze und dann auf dieser Seite anzeige, in welchen weiteren Sprachen dieser Artikel noch verfügbar ist. Wie diese Ausgabe generiert wird, ist dabei erstmal ein anderes Thema.
Ich ziele eher darauf ab, wie man die URLs dann strukturiert.

Sagen wir ich habe das hier:
domain.xy/category/500,a-sample-article (englischsprachig)

Wie sieht dann der URL für den deutschsprachigen Eintrag aus? Hat der dann einfach nur eine andere ID und übersetzten Titel und wird in der gleichen Datenbanktabelle gespeichert? Also ..
domain.xy/category/256,ein-beispielartikel (deutschsprachig)

Das finde ich ja dann wiederum nicht so prall .. hm.
Auch wenn ich zugegebe, dass ich irgendwie den Sprachparameter als solches recht unschön finde .

[Basti]

Hi Ben.

Was spricht denn gegen example.com/<lang>/…?

Ich meine, mich an einen Beitrag von Shiflett zu erinnern, in dem schreibt, er würde URL hassen, die man nicht "abkürzen" kann: example.com/de wäre aber sicher schwierig mit sinnvollem Inhalt zu füllen. Ein anderer Einwand fällt mir aber gerade nicht ein.

Gegen Subdomains sprechen natürlich Session-Cookies. Wie es sich da mit SSL-Zertifikaten verhält weiß ich nicht (vermute aber, dass die auf eine Domain und nicht auf eine Subdomain ausgestellt werden).

Weiter fällt mir zu Diskussion noch ein, dass es natürlich nicht nur die Variante gibt, eine Website 1:1 in eine andere Sprache zu übersetzen, sondern das anderssprachige Sites mitunter auch völlig anders aufgezogen werden müssen (andere Märkte/Angebot im Ausland, nicht jeder Inhalt für jede Sprache Interessant -> Notwendigkeit die Inhalte anders zu strukturieren). In dem Fall bräuchte es unterschiedliche Seitenbäume und eben optionale Assoziationen zwischen den Seiten (Seite 413 ist Übersetzung von 42). In dem Fall wäre ein example.com/en/something wieder nicht schlacht, da dieses "en" ja quasi den Knoten auf der ersten Ebene des Seiten-Baumes repräsentiert.

Sonst noch:
Es gibt nicht nur einen Standard, um Sprachen abzukürzen. Der mit den zwei Buchstaben ist die ISO-Norm 639-1, welche z.B. auch noch um Ländercodes ergenz werden kann (-> RFC 1766). ISO 639-2 sieht 3stellige Kürzel vor (-> RFC 3066).

Wenn du da Klarheit hast, was du in Zukunft verwenden willst und z.B. example.com/<lang>/<category> verwendest, dann kannst du das Sprachkürzel bis zur ersten Übersetzung auch weglassen, wenn du sicherstellst, dass keine Kategorie nach einem der Kürzel in der ISO-Norm benannt wird.

Anderer Weg wäre natürlich, dass noch klarer zu trennen:
example.com/de.category/ zum Beispiel. category darf keinen Punkt enthalten und wenn keine Sprache angegeben ist, dann wied eben die Sprache vor der Einführung der Mehrsprachigkeit hergenommen.

Noch was am Rande:
Man sieht immer wieder Flaggen zur Auswahl der Sprache. Ist natürlich grober Unfug: Flagge repräsentiert eine Nation (Esperanto mal ausgenommen) und Nation !== Sprache.

Basti

[robo47]

Zitat von $traight-$hoota

Ich würde die Sprache eher nicht so in den URL path packen, weil es eigentlich es keine komponente ist, die den inhalt/die webseite lokalisiert sondern die art der darstellung beeinflusst. deshalb sollte die sprache eher als parameter zur darstellung übergeben werden bzw. im normalfall in der session und/oder als cookie gespeichert werden und nur für änderungen der sprache explizit im url enthalten sein.

Wenn nicht via URL, hast du schonmal ein Problem mit den Suchmaschinen, weil die dann wohl nur eine Version deiner Seite kennenlernen werden.

Session+Cookie haben den Vor/Nachteil (kann man sehen wie man will), wenn man Links auf die Seite setzt, bekommt der User vielleicht nicht die Sprache die derjenige der sie ursprünglich aufgerufen hat präsentiert, sondern je nach Mechanismus der Seite entweder die Standard-Sprache oder z.b. die die sein Browser als accept-language sendet.

Ich stehe eigentlich auf den Standpunkt, eine Url sollte einen "möglichst" eindeutigen Inhalt nach aussen haben, das möglichst beziehe ich jetzt auf Login-Geschichten oder ähnliches wo man bewußt etwas tut um etwas zu sehen.

Ich würde ein /de/ in der URL bevorzugen.

mfg
robo47

[Ben]

Zitat von robo47

Wenn nicht via URL, hast du schonmal ein Problem mit den Suchmaschinen, weil die dann wohl nur eine Version deiner Seite kennenlernen werden.

Da habe ich auch schon drüber nachgedacht und deine Aussage bestätigt mich da nur!

Zitat von robo47

Session+Cookie haben den Vor/Nachteil (kann man sehen wie man will), wenn man Links auf die Seite setzt, bekommt der User vielleicht nicht die Sprache die derjenige der sie ursprünglich aufgerufen hat präsentiert, sondern je nach Mechanismus der Seite entweder die Standard-Sprache oder z.b. die die sein Browser als accept-language sendet.

Das kann aber ja wunderbar umgangen werden, indem man eben unterschiedlichen Inhalten auch unterschiedliche IDs gibt. Damit hat sich das doch eigentlich erledigt, oder?

Zitat von robo47

Ich würde ein /de/ in der URL bevorzugen.

Ich auch, auch wenn es eventuell etwas mehr Aufwand bedeutet

[robo47]

Zitat von Ben

Das kann aber ja wunderbar umgangen werden, indem man eben unterschiedlichen Inhalten auch unterschiedliche IDs gibt. Damit hat sich das doch eigentlich erledigt, oder?

Wenn die Struktur von der Sprache beeinflust ist, wird das halt auch deutlich komplexer für das System:

www.domain.tld/neuigkeiten/
www.domain.tld/news/
www.domain.tld/nouvelles/

3 Links für das gleiche, so hat man dann quasi auch über die URL erkannt welche sprache es ist, aber dann brauch ich auch keinen Cookie(Session) mehr oder habe ich dich da falsch verstanden ?

mfg
robo47

[Ben]

Zitat von robo47

Wenn die Struktur von der Sprache beeinflust ist, wird das halt auch deutlich komplexer für das System:

www.domain.tld/neuigkeiten/
www.domain.tld/news/
www.domain.tld/nouvelles/

Braucht man ja im Prinzip nicht. Ein Sprachparameter mit standardmäßig englischsprachigen Bezeichnungen reicht imho voll aus.
Das andere wäre nur ein Gimmick!

[robo47]

willst du das /de/ rein für verschiedene Sprachen der bedienoberfläche etc, oder eben auch er inhalte ? Weil du oben angesprochen hast:

Zitat von Ben

Das kann aber ja wunderbar umgangen werden, indem man eben unterschiedlichen Inhalten auch unterschiedliche IDs gibt. Damit hat sich das doch eigentlich erledigt, oder?

meinst du mit einer anderen ID nicht den Namen ? Als beispiel:

www.domain.tld/de/tutorials/1-tutorial-ueber-php

wäre dann für dich die englische version so:

www.domain.tld/en/tutorials/1-tutorial-ueber-php

oder so:

www.domain.tld/en/tutorials/2-tutorial-about-php

[Ben]

Hi,
also ich weiß halt nicht was besser ist.
Meine Aussage war auf deine "Session"-Aussage bezogen.
Ist schon klar, dass es der zweite URL Unsinn ist.

Es ist imho nicht praktikabel einen Artikel mehrsprachig, aber mit der gleichen ID darzustellen.

Ich würde jetzt gerade für so etwas plädieren

• domain.xy/de/tutorials/123,php-loginsystem-mit-sessions
• domain.xy/en/tutorials/593,how-to-build-a-php-login-system-with-sessions

Was dann im Hintergrund heißen würde, dass alle Tutorials, egal in welcher Sprache in nur einer einzigen DB-Tabelle gespeichert würden und die ID halt die des Datensatzes ist.
Quasi wäre ein englischer/andersprachiger Artikel nichts anderes als ein neuer Artikel, aber eben nicht in deutscher Sprache.

[robo47]

Zitat von Ben

Quasi wäre ein englischer/andersprachiger Artikel nichts anderes als ein neuer Artikel, aber eben nicht in deutscher Sprache.

Okay, das war es um was es mir ging. Dann musst du dir aber auch sehr genau überlegen wie am Ende das "Umschalten" stattfindet, angenommen ich bin auf einer Seite und sehe irgendwo einen Link mit "Deutsch / Englisch" oder ne passende Flagge und ich befinde mich in nem Artikel, wohin zeigt der Link dann ? www.domain.tld/de/ bzw. www.domain.tld/en/ ? Weil es ist ja keine Zuordnung möglich, wegen verschiedene Ids, bzw. nicht alle Beiträge sind in allen Sprachen vorhanden ?

[Ben]

Na, das weiß ich ja eben nicht.
Ich suche ja nach einer Möglichkeit, wo ich z.B. sagen kann

"Dieser Artikel ist in folgenden weiteren Sprachen verfügbar"
Quasi so ein Stil, wie bei Wikipedia praktiziert. Das finde ich persönlich nämlich sehr gut, damit man nicht von Beginn an unter Druck steht auch wirklich jeden Artikel mehrsprachig anzubieten.

Es ist eben die Frage, ob wirklich eine DB-Tabelle ausreicht oder ob man pro Sprache eine nimmt, welche dann über eine weitere Tabelle miteinander verknüpft sind (also die entsprechenden Artikel).

Keine Ahnung wie .. das ist alles recht komplex und deshalb wollte ich auch gerne hier Hilfe suchen, weil ich alleine das nicht hinbekommen habe.
Wollte zu Beginn eigentlich auch direkt einen Thread im Datenbanken-Forum aufmachen, aber habe es dann gelassen. Nun sind wir an dem Punkt angelangt, wo wir auch darüber sprechen (müssen) .

[$traight-$hoota]

man muss natürlich unterscheiden, ob die mehrsprachigen seiten alle den gleichen inhalt haben, also eine lediglich eine übersetzung sind, oder ob die lokalisierten seiten umfangreichere unterschiede enthalten. handelt es sich lediglich um übersetzungen, würde ich die seiten im url gleich benennen und unter der gleichen id führen, weil sie ja inhaltsgleich sind - nur die sprache unterscheidet sich. wie diese unterscheidung getätigt wird ist für diese überlegung erstmal unwichtig; sie kann aber nicht durch seitentitel in unterschiedlichen sprachen geschehen, aber das ist sowiso keine gute idee, weil es viele wörter auch in mehreren sprachen gibt und so keine eindeutige zuordnung seitentitel->sprache möglich ist.

Zitat von robo47

Wenn nicht via URL, hast du schonmal ein Problem mit den Suchmaschinen, weil die dann wohl nur eine Version deiner Seite kennenlernen werden.

es muss natürlich auch möglich sein, per url die sprache ändern zu können. ich weiß jetzt nicht, wie gut das von sumas umgesetzt wird, aber theoretisch können die andersprachigen versionen per link-tag mit rel="alternate" und ggf. hreflang verlinkt werden.
aber im normalfall wählt ein user eine sprache und möchte dann die seite auch immer in dieser sprache präsentiert bekommen, also gehört die sprache quasi zu den programmeinstellungen und muss nicht jedes mal angegeben werden.

um per seitenaufruf (wie die alternate-links für sumas) die sprache ändern zu können würde ich also eher einen parameter verwenden. beispielsweise www.domain.tld/path/to/page?lang=de oder www.domain.tld/path/to/page;lang=de etc.

Zitat von robo47

Session+Cookie haben den Vor/Nachteil (kann man sehen wie man will), wenn man Links auf die Seite setzt, bekommt der User vielleicht nicht die Sprache die derjenige der sie ursprünglich aufgerufen hat präsentiert, sondern je nach Mechanismus der Seite entweder die Standard-Sprache oder z.b. die die sein Browser als accept-language sendet.

wenn es sich um identischen inhalt nur in verschiedenen sprachen handelt, ist dass eigentlich kein problem, sondern demjenigen, der den link anklickt, wird die seite so angezeigt, wie er sie nach den angaben am ehesten haben möchte.

wenn jede sprache teilweise eigenständige inhalte, kategorien, unterschiedliche seitenstrukturen etc. hat, bringt das alles natürlich nichts, dann sollte auch die sprachbezeichnung der hauptknoten sein, von dem dann jeweils unterschiedliche bäume abhängen.

[Ben]

Zitat von $traight-$hoota

man muss natürlich unterscheiden, ob die mehrsprachigen seiten alle den gleichen inhalt haben, also eine lediglich eine übersetzung sind, oder ob die lokalisierten seiten umfangreichere unterschiede enthalten.

Was heißt umfangreiche Unterschiede?

Es ist quasi so wie bei Wikipedia, um das mal als bekanntes Beispiel zu verwenden. Es gibt einen Artikel zu einem Thema, als Beispiel ein Tutorial. Dies muss aber nun natürlich nicht die gleiche Länge, auch wenn es das selbe Thema behandelt.
Verstehst du was ich meine?

Zitat von $traight-$hoota

aber im normalfall wählt ein user eine sprache und möchte dann die seite auch immer in dieser sprache präsentiert bekommen, also gehört die sprache quasi zu den programmeinstellungen und muss nicht jedes mal angegeben werden.

Das ist korrekt, aber generiert man dann nicht unweigerlich double content?

Zitat von $traight-$hoota

domain.tld/path/to/page;lang=de

Durchaus interessanter Gedanke, allerdings wird es zu genau 100% eine ID innerhalb des URL geben und diese muss, wie oben angesprochen ja nicht unbedingt bei den unterschiedlichen Sprachversionen eines Artikels gleich sein.

[Basti]

Zitat von Ben

Was heißt umfangreiche Unterschiede?

Meinen Beitrag überlesen?

----

Was das DB-Layout angeht:
Natürlich gehören alle Artikel (wenn sie vom gleichen Typ oder so sind) in eine DB-Tabelle. Es taugt nicht, für jede Sprache eine eigene Tabelle anzulegen.

Und die Zuordnung ist doch kein Problem. Entweder hast du eine gerichtete Verbindung, sagst also "A ist eine Übersetzung von B", dann reicht eine einfache Tabelle mit id, a und b (die Sprache ist ja eh bei den Inhalten selbst mit angegeben/gespeichert). Die Abfrage ist dann halt ein wenig aufwändiger, da du ja erstmal nach der Urfassung suchen musst und dann alle Übersetzungen von dort aus finden musst. Um Konflikte zu vermeiden sollten dann auch alle Übersetzungen als Übersetzung der Urfassung geführt werden.

Der einfachere Weg ist, dass du tatsächlich sowas, wie einen Container bildest, in den du dann die einzelnen Inhalte in den unterschiedlichen Sprachen reinlegst. So bekommt jeder Inhalt neben seiner eigenen ID noch eine ID verpasst, die sich alle Seiten (etc.) teilen, die die Inhalte in mehreren Sprachen darstellen.

Wenn du das kombinierst, kannst du diese ID mit der ID der Seite/des Artkels, der eine Information als erstes in irgendeiner Sprache darstellt gleichsetzen und kannst so ohne viel Aufwand eine Seite nachträglich mehrsprachig machen.

Beispiel:

Artikel-ID wäre die eindeutige ID eines jeden Artikels in seiner eigenen Sprache, Informations-ID wäre die ID der Information, die in mehreren Sprachen wiedergegeben werden soll.

1. Artikel "Über uns" wird angelegt:
Artikel-ID: 42, Info-ID: 42 (oder irgendwas anderes)

2. Artikel "About us" wird angelegt:
Artikel-ID: 316, Info-ID: ebenfalls 42, da Übersetzung von Art. 42

3. About us wird übersetzt ins Japanische:
Artikel-ID: 317, Info-ID: wieder 42

Wenn die Übersetzung tatsächlich 1:1 sein soll, dann wäre natürlich sowas als ID für die Artikel ausreichend: 42-de, 42-en, 42-jp. Ist aber natürlich starrer, unflexibler.

Basti

[Jann Hendrik]

auch wenn es den Kern der Diskussion gerade nicht ganz trifft:
http://modrewrite.de/foren/ftopic3106.html#15665
hier ist eine schöne Form das de oder en automatisch zu setzen.
Jenachdem, was hier in diesem thread rauskommt ggf. gut zu nutzen!

[Ben]

Habe deinen Beitrag schon gelesen Basti, allerdings muss ich gestehen, dass ich da nicht so wirklich etwas Hilfreiches, für mich, rauslesen konnte.

Geht mir ähnlich mit der Info-ID. Soll die deiner Ansicht nach auch in den URL?
Das missfällt mir dann schon.

[dago]

Zitat von Ben

Geht mir ähnlich mit der Info-ID. Soll die deiner Ansicht nach auch in den URL?

Nö, nicht zusätzlich, sondern anstatt der Artikel-ID. Die Seite selbst soll unabhängig von der Sprache mit der eindeutigen ID angesprochen werden. (Falls überhaupt eine ID in die URL muss)

Erst danach, je nach gewählten Sprache, soll der passende Artikel gewählt werden.

[Ben]

Eine ID wird es im URL geben, da brauchen wir gar nicht drüber sprechen.
Ich verstehe einfach das Beispiel von Basti nicht. Wie würden denn die URLs zu den Punkten 1. bis 3. aussehen? :-/

[dago]

Also das währen dann die URLs:

• domain.xy/de/tutorials/123,php-loginsystem-mit-sessions
• domain.xy/en/tutorials/123,how-to-build-a-php-login-system-with-sessions

Die 123 steht hier nicht für die Artikel-ID, sondern für die Info-ID (wie Basti es genannt hat).

Der erste Artikel der geschrieben wird, hat die gleiche Artikel-ID, wie Info-ID. Da die Info-ID sich ja auf den bezieht. Weitere Artikel (Übersetzungen des Artikels 123) sind ja in der gleichen TB und haben auch andere Artikel-ID 345, 486. Aber die gleiche Info-ID 123. Da es Übersetzungen von dem Artikel 123 sind.

Keine Ahnung ob ich das jetzt verständlicher geschrieben habe.