• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Multilinguale website, wie?

A

Animal21

Neues Mitglied
hallo leute,
zuerst einmal: euch fehlt ein "Allgemein"-bereich xD
Daher poste ich diesen threard mal hier, damit die anfänger nich alle ihren senf dazugeben *fg*

Hier mein anliegen:
Hatte bei meiner privaten Website in dem wissen, dass diese nur deutsch und englisch sein sollte, eine quick&dirty methode für die mehrsprachigkeit gewählt, welche folgende wäre:
ich hab einfach in den content-tabelle jeweils eine title_de, title_en; content_de, content_en unso weiter spalte erstellt un dann per php jeweils bei der abfrage die sprache de bzw. en mit drangehangen...
Das geht auch sehr gut un is für meine privaten zwecke ausreichend.

Nun bin ich aber dabei, eine Website für meine Company zu erstellen und stehe wieder vor dem Sprachenproblem.
Zum einen ist bekannt, dass es erstmal nur deutsch und englisch geben wird. Aber da man(n) ja nie wissen kann und wir doch alle gern alles generalisieren, würde ich gern von vornherein sowas wie ein language-framework schaffen.

Die website hat ein eigenprogrammiertes kleines CMS, welches auf die website zugeschnitten ist, daher bitte keine vorschläge wie "nimm joomla!".

Ich dacht entweder nehm ich wieder meine quick&dirty variante oder etwas eleganteres, leider fehlen mir die ideen etwas...
Dacht evtl. an angtrennte language tabellen mit keywords, welche dann geweils abgerufen werden...

was sagt ihr dazu?

mfg
ani
 
Hättest Du bei Deiner privaten Website das Datenmodell richtig gewählt, wär schon alles in schönster Ordnung. Es muß so aussehen:
ausgabetext_id | sprachkennzeichen | ausgabetext.
Das läßt sich wunderbar abfragen und beliebig erweitern.
 
@momo95, so einfach ist das nicht, da CMS.
folgendes:
die website wird in pages geteilt (jeweils die menupunkte im globalmenu und den jeweiligen submenus), auf diesen pages können beliebig modules eingebunden werden. jeder moduletyp hat eine eigene tabelle, in welcher die inhalte bisher gespeichert werden... in einer weiteren tabelle "installed_modules" wird die zuweisung zu den pages hinterlegt.

Gedanke eins wäre, einfach in der jeweiligen module_typ-tabelle die spalten title_de, title_en, bzw content_de und content_en, u.s.w. zu erzeugen un dann per lang in der sql abfrage entsprechend zu holen: "select title_".$_SESSION['lang']." from tabelle where id=x" <-- so mach ich das momentan auf meiner privaten seite
 
Wenn Du pro Sprache eine Tabellenspalte anlegst, gibt das ein elendes Gefummel bei jeder einzelnen Abfrage und noch mehr bei einer Erweiterung. Das Stichwort heißt Normalisierung.
 
also ich würd schon gern in der datenbank bleiben...und nicht auf datein ausweichen wollen..

wie wärs mit einer keyword-tabelle, in welcher standard felder wie, buttons, bezeichnungen etc hinterlegt sind un dann eine language tabelle, in der ein eine id und für jede sprache eine spalte angelegt wird:
in den modul-typen tabellen könnte ich dann bei den inhalts-spalten dann einfach die id der language-table angeben... und dann per php die sprache in der select anweisung übergeben...

würde doch gehn, aber wie sieht das dann mit der performance aus?
jede inhalt müsse über 2 abfragen geholt wreden:
einmal muss ich auslesen was im module selbs steht un dann noch abfragen, für jede inhalts-spalte, welcher text drin steht...

könnte bei eine page mit vielen modulen etwas viel werden, oder?

bzw wenn ich EINE language-table für die gesamte website hab, wird die iwann recht lang...
 
ausgabetext_id | sprachkennzeichen | ausgabetext
1 | 1 | Willkommen
1 | 2 | Welcome
1 | 3 | Bienvenue
2 | 1 | Auf wiedersehen
2 | 2 | Good bye
2 | 3 | Au revoir

Du übergibst also einfach die ausgabetext_id und das Sprachkennzeichen und kannst zukünftig ohne die geringste Änderung im Quellcode beliebig viele Sprachen verwalten.

EINE language-table für die gesamte website hab, wird die iwann recht lang...
Zum Vergrößern anklicken....
Schau Dir die Reaktionszeit von MySQL an, einige 10-tausend DS sind in Sekundenbruchteilen durchsucht (eine vernünftige Indizierung vorausgesetzt).
Aus Gründen der einfacheren Wartung würde ich höchstens die "Standardtexte" mit einer hohen Lebensdauer von den häufiger wechselnden "Inhaltstexten" trennen. Vom Prinzip her ist das nicht nötig.
Du kannst auch sehr einfach eine Defaultsprache festlegen. Falls ein Text in der gewünschten Sprache nicht angelegt ist, weichst Du auf den default aus.
 
Sicher kann man mit richtigem Cache die Abfragen optimieren. Die Datenbank bezüglich Mehrsprachigkeit muss sowieso normalisiert werden.

Warum man aber für den statischen Inhalt keine Standardtools nutzt erschließt sich mir nicht.

Ein $this->translate('Welcome') ist viel bequemer als ein $this->translate(1). Die Keys- vs. Strings-Diskussion ist zwar berechtigt, aber Nummern als Keys sind viel zu unbequem.
 
naja, dass is im grunde, was ich vorschlug:
module_01-table
id | pageID | title | subtitle | content
0 1 0 1 2

language-table
id | de | en | es
0 ja yes si
1 nein no no
2 hallo hello hola

$res1 = "select title, subtitle, content from module_01-table where id = x and pageID = y"
execute+fetch_assoc...
$title = "select ".$_SESSION['lang']." from language-table where id = ".$res1['title']."
$subtitle = "select ".$_SESSION['lang']." from language-table where id = ".$res1['subtitle ']."
$content = "select ".$_SESSION['lang']." from language-table where id = ".$res1['content ']."

oder?

edit: @crash, warst schneller xD
nun, da fast alles vom cms nutzer verändert werden kann, was einen text hat, außer sehr weniger ausgaben und befehlen... lohnt sich ein externes framework doch nicht... oder?
 
naja, dass is im grunde, was ich vorschlug:
Zum Vergrößern anklicken....
Nee, der Unterschied liegt in der Normalisierung; um das zu verdeutlichen, habe ich 2 Beispiele in die Tabelle eingetragen. Normalisierung gibt Geschwindigkeit und Sicherheit und Wartungsfreundlichkeit und Vollautomatik bei den Abfragen.
Believe me or not, your decision.
 
is meins nich normalisiert
Zum Vergrößern anklicken....
Nee, isses nich.
Wenn Du bei Deiner Konstruktion eine neue Sprache einführen willst, mußt Du Spalten an die Tabelle anfügen. Daraus folgt, daß alle Abfragen geändert werden müssen.
Bei der normalisierten Konstruktion legst du eine neue Spach-Id an (z. B. 4 für spanisch), trägst deine Texte ein und bist fertig.
 
also ich müsste bei meiner nur eine spalte für eine neue sprache hinzufügen un dann die zeilen füllen, aber ich müsste KEINE abfrage ändern, da die spalte ja dynamisch über die php-variable 'lang' aus der session oder settings in die select genommen wird.
 
Du sagtest ja eingangs schon, daß Du bis dato eine quick-and-dirty-Lösung hast.
Wechselnde Spaltennamen in einer Abfrage machen nur Kummer. Es wird schon ein elendes Gefummel, wenn Du PDO einsetzt und die Abfrageparameter an die Variablen binden willst.
Würde diese unprofessionelle Vorgehensweise irgendwo Vorteile bringen, wär's ja vielleicht 'ne Diskussion wert. Aber Du hast nur Nachteile.
Also entweder richtiger Datenbankeinsatz oder Zettelkasten (soll heißen Textfiles), alles andere ist Murks.
 
hmm ok, dann nochma für langsame:

hab z.b. das modul contentbox, dieses besitzt als inhalt einen title, subtitle und content
is folgendes dann richtig?
Languages:
sprachkennzeichen | sprache
1 | German
2 | English
3 | France
Language-Table:
ausgabetext_id | sprachkennzeichen | ausgabetext
1 | 1 | Willkommen
1 | 2 | Welcome
1 | 3 | Bienvenue
2 | 1 | Auf wiedersehen
2 | 2 | Good bye
2 | 3 | Au revoir
3 | 1 | Hallo
3 | 2 | Hello
3 | 3 | Bonjour
...
...

contentbox:
id | pageID | title | subtitle | content
0 | 1 | 1 | 2 | 3
1 | 1 | 4 | 5 | 6
<-- also, dass in den inhalts-spalten nur die ausgabe-id steht?

mfg
ani
 
Ne, das haut so nicht hin.

Du würdest dir in deiner contentbox-Tabelle Redundanzen einhandeln, wenn du Spalten wie created_on oder edited_on hinzufügen würdest.

Vielleicht mehr so:

Code: 
language

id | name
---+---------
 1 | German
 2 | English
 3 | France


page

id | created_on | edited_on
---+------------+-----------
 1 |        ... |       ...


page_l10n

id | page_id | language_id | title      | subtitle        | content
---+---------+-------------+------------+-----------------+---------
 1 |       1 |           1 | Willkommen | Auf wiedersehen | Hallo
 2 |       1 |           2 | Welcome    | Good bye        | Hello
 3 |       1 |           3 | Bienvenue  | Au revoir       | Bonjour

- http://en.wikipedia.org/wiki/L10n
 
alles klar funktioniert super...
danke für eure hilfe und geduld! :)

also kann schon normalisieren, aber ich muss zugeben, dass ich oft zu faul bin bis NF4/5 zu gehn, bzw oft ist es auch einfach nicht nötig... aber dies ist wohl jedem selbst überlassen, bzw abhängig von der komplexizität des projektes und der tabellen...

mfg
ani

danke nochmal
 
Die 3. Normalform sollte für die meisten Sachen auch ausreichen. Es ist hier wie mit allen Dingen: etwas mehr Mühe und Zeit in die Vorbereitung gesteckt und hinterher ein stabiles, leicht zu wartendes System haben.
(Da spricht ein alter Handwerker)
Schön, daß es funktioniert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben