Mehrsprachigkeit - wie am besten?

[c4]

Moin,

ich plädiere dafür, dass man das Forum von 'Off-Topic' in 'c4s Forum' umbenennt. [1]

Das Ding würde ich ganz gerne mehrsprachig aufbauen. Wenn schon komplex, dann richtig...

Wie speichert man die Texte am besten?
MySQL? Textdatei? Wenn ja, wie spreche ich die Text(bausteine) dann an? über ihre IDs? Extra Stichworte ausdenken?

Da ich der französischen, albanischen, hinterrückswäldigen, ... Sprache nicht mächtig bin, wäre es ganz praktisch, wenn man die Übersetzungsarbeit anderen überlasst. MySQL wäre also vermutlich ungünstig. Oder?

Oder macht man es ganz anders: Mit einem Templatesystem. Also nicht der Text wird eingefügt, sondern der restliche Inhalt wird zum Text gepackt.

Gebt mir einfach mal ein bisschen INSERT, wie man das praktikabel machen könnte.


Dank Euch
Carsten




[1] Scherz!

[Gweilo]

Also einige Foren machen das so, ich denke die wissen schon weshalb.

$txt[1] = "wasauchimmer";
$txt[2] = ....

Ich denke mir jedoch, dass MySQL die schnellere Variante wäre, da ja nicht bei jedem Seitenaufruf jeder Text gelesen werden muss. Ich weiss nicht wie PHP das caching handhabt, und so eine Datei griffbereit hat, aber vermutlich gibts da keine so grossen einbussen.

Habe zzt ein relativ grosses projekt mit bald 700 texten (in einer txt datei gespeichert) und das ganze läuft sehr flott. So ist's relativ einfach zum übersetzen für OttoNormalo.

Wegen dem Übersetzen von MySQL texten sollte das nicht so ein problem darstellen. es ginge sogar einiges besser als mit der TXT datei, nämlich könntest du auf der Seite selbst, wenn man eingeloggt ist, bei jedem text ein kleines Edit-Symbol hinsetzen, so dass die texte gleich im browser editiert/übersetzt werden können.

edit:

Extra Stichworte ausdenken?

würde ich nicht tun, da id's schneller sind, da diese nicht gehasht werden müssen.

[c4]

Wenn ich es mir recht überlege, ist das mit den IDs doch nicht soooo schlimm.
Wichtig wäre nur, dass man viele Standardtexte ('OK', 'Ja', 'Bitte auswählen', 'Eingaben korrekt?', ...) nicht für jede Seite neu einträgt. Diesen Einträgen könnte man dann vielleicht doch ein Stichwort gönnen, damit es sich so leichter arbeiten lässt.

Die Idee mit dem Webfrontend für die Überetzung finde ich genial einfach. War mir wohl zu simpel, um selber darauf zu kommen...
Damit verbunden ist auch, dass ich MySQL nehme, logisch.

Wie macht man das dann eigentlich auf jeder Seite? Man liest mit einer Abfrage alle Texte aus und spricht in aus dem entstandenen Array direkt den gewünschten Wert an. Für jeden Text eine Abfrage bringt's wahrlich nicht.

Eleganter wäre natürlich nur die Textbausteine aus der Tabelle zu holen, die auch auf der Seite benötigt werden. Aber das müsste man ja warten. Mal schauen. Lässt sich ja einfach abändern.

[Gweilo]

Original geschrieben von _c_4_
Wie macht man das dann eigentlich auf jeder Seite? Man liest mit einer Abfrage alle Texte aus und spricht in aus dem entstandenen Array direkt den gewünschten Wert an. Für jeden Text eine Abfrage bringt's wahrlich nicht.

Eleganter wäre natürlich nur die Textbausteine aus der Tabelle zu holen, die auch auf der Seite benötigt werden. Aber das müsste man ja warten. Mal schauen. Lässt sich ja einfach abändern.

1.a) ja
1.b) Abfrage? Meinst du jetzt eine mySQL abfrage oder bist du noch beim array? Wenn letzeres, warum bringt's das nicht? array abfragen geht in konstanter laufzeit.
2) Wenn du das mit txt-dateien vorhast, dann viel spass ;c) Ansonsten müsstest du halt bei jedem DB-eintrag die zugehörigkeit angeben (entweder "alles", für oft gebrauchte begriffe), oder halt die Seite. (das ganze selbstverständlich als mehrfach INDEX deklariert, zuerst die id, dann die zugehörigkeit)

oder: oft gebrauchte wörter in die textdatei und bei jedem seitenaufruf reinladen, und seitenspezifische in die DB. Bei den oft gebrauchten kommen ja nicht alltag neue hinzu.

[c4]

1) Zu 1.b): Jo, 'Abfrage' meinte MySQL. Ich tippe manchmal schneller, als ich denke, sorry. :)

Eine entsprechende Tabelle wurde nun zum Aufbau hinzugefügt:

cmd_text_modules
    id              INT AUTO_INCREMENT PRIMARY KEY,
    text_module     TEXT,
    keyword         VARCHAR(50)

Reicht eigentlich aus.

[Gweilo]

Was ist Keyword?

Falls es die seitenzugehörigkeit ist, ist mir eben aufgefallen, dass das gar nichts bringt bei der Datenbank, da du sowieso über die id suchst.

nochmals zu 1.b) Jetzt machst du ja doch für jeden Text eine abfrage. Ich finde das überhaupt nicht tragisch, denn solche abfragen über den Primary key gehen ganz flott, auch bei sehr grossen Datenbanken.

[c4]

Mit keyword dachte ich eher an die oben erwähnten Stichworte: 'OK', 'Ja', 'Bitte auswählen', 'Eingaben korrekt?', usw. Felder, die man also oft braucht. Sich dafür extra die ID zu merken ist ja nicht ganz das Wahre.

Zum Thema Abfrage. Ich dachte mir das eher so:

PHP-Code:

$result=mysql_query('SELECT CASE WHEN keyword=NULL THEN id ELSE keyword END, text_module FROM cmd_text_modules', $conn);
while (list($id, $text_module)=mysql_fetch_row($result)) {
    $text_modules[$id]=$text_module;
} 


Ob das so funktionieren wird weiß ich nicht, aber das ist zumindest die Idee.
Texte werden dann also einfach über $text_module['ok'] oder $text_module[743] angesprochen.

[Gweilo]

Jetzt verstehe ich, was du meinst, aber da geht der ganze vorteil von MySQL flöten. So hast du ja doch wieder die ganzen texte unnötig in arrays.

Die id's einzeln anzusprechen ist einiges schneller (vor allem bei einer grossen datenbank). Im Schnitt sind es ja pro seite 30 Texte oder so, das sind dann 30 einzelne abfragen, verglichen mit dem verarbeiten und auslesen aller texte ist das nichts.

Ich würde das so etwa machen:

PHP-Code:

function txt($id)
{
  GLOBAL $lng;
  $result=mysql_query("SELECT text FROM cmd_text_modules WHERE id='".$id."' AND language='".$lng."'");
  $row = mysql_fetch_row($result);
  return $row[0];
} 


aufgerufen wird dann mit txt(165);

Das mit den keywords würde ich sein lassen. Das nützt nur dir beim programmieren ein bisschen (und nicht viel) und ist später nur hinderlich.

Was duch machen kannst, wenn du texte rasch nachschauen musst, um die id herauszufinden, einfach eine datei im editor offen halten mit einem Dump der datenbank (nur eine sprache).

Dann suchst du rasch das wort mit ctrl-f und schon hast du die id. Ich hatte es ja mit der txt[] möglichkeit gemacht und bin auch so vorgegangen - und es kamen sehr wenig wiederholungen der wörter vor!

edit: bevor ich's vergesse. die ID wäre in dem fall nicht primary, es wären beide felder id und language als INDEX zu definieren (beide in einem index, zuerst id, dann language, da du mehr ids als sprachen hast)

[c4]

Okay, hast mich überzeugt!

Mir ist nebenbei noch was dummes aufgefallen: Ich hatte in meinem Tabellenentwurf die Sprache vergessen... :) Jetzt ist's sinnvoller:

cmd_text_modules
    id              INT AUTO_INCREMENT PRIMARY KEY,
    language_id     INT,
    text_module     TEXT

cmd_text_languages
    id              INT AUTO_INCREMENT PRIMARY KEY,
    language        CHAR(2)

Da es ohne Indizierung der Felder nicht sonderlich flott gehen dürfte, packe ich lieber wieder ordentliche IDs rein.

Eine Frage habe ich aber doch noch: Hast Du Belege für die Behauptung, dass es mit den IDs so verdammt schnell geht?

[Gweilo]

die indexe sind b-bäume, das bedeutet, dass der index in logarithmischer laufzeit gefunden wird.

noch kurz was zu deiner struktur:

cmd_text_modules
    id              INT AUTO_INCREMENT PRIMARY KEY,
    language_id     INT,
    text_module     TEXT

cmd_text_languages
    id              INT AUTO_INCREMENT PRIMARY KEY,
    language        CHAR(2)

Warum extra eine Datenbank und nicht language_id CHAR(2) als index benutzen? Tabellen-verknüpfungen sind relativ mühsam und verlangsamen das ganze unnötigerweise.

ich würde das so machen

CREATE TABLE `cmd_text_modules` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
`language` CHAR( 2 ) NOT NULL ,
`text_module` TEXT NOT NULL ,
INDEX ( `id` , `language` )
);

id darf nicht PRIMARY sein, da der selbe text ja die gleiche id haben muss in den verschiedenen sprachen. den INDEX habe ich zusammengeführt, da du ja immer WHERE id='' AND language='' abfrägst.

nur so am rande, ein ganz interessanter artikel zu indexes: http://www.sitepoint.com/article/opt...ql-application