nicht angemeldet
Idee zur Mehrsprachigkeit
MudGuardHallo Leute,
ich will schon eine Zeit lang mal endlich "Mehrsprachigkeit" in mein Projekt einbauen. Mir ist da gerade eine Idee gekommen, wie das am einfachsten umzusetzen wäre. Das wollte ich einfach mal allen mitteilen und hoffe, dass der ein oder andre auch Lob, Kritik, Anregungen beisteuern mag :)
Es geht vor allem um winzige bis mittlere Textpassagen. Also von einzelnen Wörtern (z.B. Labels in einem Formular) bis zu ein paar Sätzen (Fehlermeldungen, Hinweis-/Hilfetexte etc.)
Da wird ja glaube ich meistens eine Lösung vorgeschlagen, dass man irgendwo in einem Array oder sonstwo die Texte speichert und sie z.B. über $lang['error_username'] ausgibt. Im Array wäre dann z.B. "Fehler: Sie haben einen falschen Usernamen eingegeben!" gespeichert.
Das ist mir irgendwie zu umständlich, weil ich dann immer die Array-Keys ('error_username') im Kopf haben muss bzw. immer hin und her gucken muss, was was bedeutet.
Jetzt meine Idee:
Es gibt eine Funktion lang($text)
Wenn ich z.B. eine Fehlermeldung habe, gebe ich sie so aus:
echo lang("Fehler: Sie haben einen falschen Usernamen eingegeben!");
Die Funktion guckt dann erstmal, welche Sprache die richtige ist. (Dazu habe ich mal für ein Uni-Projekt eine hübsche - und ich hoffe, gute - Language Negotiation gemacht. Aber das ist ein anderes Thema).
Wenn DE die Zielsprache ist, gibt die Funktion einfach $text zurück, so wies reinkam.
Wenn EN oder sowas die Zielsprache ist, sucht die Funktion da wo die Texte herkommen (hab mich noch nicht entschieden - Textfile, Array, DB etc. s. auch unten) nach einem Treffer. Wenn die richtige Textpassage gefunden wurde, wird diese zurückgegeben.
Wird nichts gefunden, gibt er hilfsweise die Deutsche zurück. Gleichzeitig wird an den Admin eine Fehlermeldung geschickt, dass die entsprechende Passage nicht gefunden wurde.
Was haltet ihr davon?
Zur Text-Quelle:
Am übersichtlichsten wäre es sicher, die Wörter/Texte in einer DB zu speichern und für jeder Sprache eine Spalte zu haben. Wenn jetzt aber für jeden Begriff der auftaucht die DB angeworfen werden muss, ist das sicher lästig für die.
Ich hab mir überlegt, das ganze in der DB zu organisieren. Anschließend wird dann aus dem DB-Inhalt (bei jeder Änderung) eine statische PHP-Include-Datei generiert, wo die Daten in einen Array kommen (oder in ein Textfile).
Was haltet ihr davon?
Bin schon auf die Antworten gespannt. Da ich heute in den Urlaub fahre, werde ich mich nicht mehr lange zurückmelden können - aber ich werde es ganz bestimmt danach weiterlesen.
Gruß
Alex
-
Hallo,
...weil ich dann immer die Array-Keys ('error_username') im Kopf haben muss bzw. immer hin und her gucken muss, was was bedeutet.
OK, nachvollziehbar, aber:
Wenn ich z.B. eine Fehlermeldung habe, gebe ich sie so aus:
echo lang("Fehler: Sie haben einen falschen Usernamen eingegeben!");hier musst Du ja die komplette und exakte deutsche Phrase im Kopf haben, damit er ggf. die anderssprachige Entsprechung findet - oder habe ich da was falsch verstanden?
Grüße Basti
-
Hi,
Wenn ich z.B. eine Fehlermeldung habe, gebe ich sie so aus:
echo lang("Fehler: Sie haben einen falschen Usernamen eingegeben!");hier musst Du ja die komplette und exakte deutsche Phrase im Kopf haben, damit er ggf. die anderssprachige Entsprechung findet - oder habe ich da was falsch verstanden?
Nein, ich habs mir ein bisschen anders vorgestellt.
Wenn ich das so ins Skript schreibe erfinde ich praktisch erst die deutsche Phrase. Wenn ich nicht gleich dran denke, den Datensatz in der Sprachdatei anzulegen, bekomme ich beim Aufruf ja eine Fehlermeldung. So entsteht dann eine Liste mit Phrasen, die ich übersetzen muss. Im Endeffekt dürfte dann nichts verloren gehen.
Mir fällt grad auf, dass aber nach einer Zeit sicherlich ein Überschuss entsteht. Also wenn ich einen Satz leicht umformuliere im Deutschen (im Skript) dann wird er ja nicht mehr gefunden. Ich bekomm ne Fehlermeldung und übersetze ihn. Der alte Satz ist dann immer noch in der DB/Sprachdatei drinnen.
Entweder man lässt das so, oder lässt sich vielleicht noch was einfallen, was man dagegen tun kann. Die beste Möglichkeit wäre natürlich, das gleich zu tun - aber ich bin vergesslich ;)
Gruß
Alex-
Ich habe das bei meinem kleinen Browsergame so gelöst, dass ich eine Tabelle in der Datenbank habe, jeweils eine Spalte mit dem "Abfrage Namen" eine mit der Deutschen übersetzung, eine Englisch und eine Spalte mit der Spanischen übersetzung.
Am Anfang meiner PHP datei lade ich alles in ein array:
$dictionary["Abfrage Name"] = "Übersetzung der ausgewählten Sprache";Die Sprache steht in den Usereinstellungen.
Ich finde meine Lösung gut, da der Quellcode nicht unnötig lang wird.
-
Wer bewertet sowas als fachlich hilfreich?
Ich habe das bei meinem kleinen Browsergame so gelöst, dass ich eine Tabelle in der Datenbank habe, jeweils eine Spalte mit dem "Abfrage Namen" eine mit der Deutschen übersetzung, eine Englisch und eine Spalte mit der Spanischen übersetzung.
Ich finde meine Lösung gut, da der Quellcode nicht unnötig lang wird.
Gute Lösung : kurzer Code = Dunkle Seite der Macht : schnell und verführerisch
-
-
-
-
Hi!
Jetzt meine Idee:
Es gibt eine Funktion lang($text)
Wenn ich z.B. eine Fehlermeldung habe, gebe ich sie so aus:
echo lang("Fehler: Sie haben einen falschen Usernamen eingegeben!");Du hättest dich vorher über die bereits existierenden Systeme informieren sollen, dann wärst du vielleicht auch über gettext gestolpert.
Lo!
-
Hi,
Du hättest dich vorher über die bereits existierenden Systeme informieren sollen, dann wärst du vielleicht auch über gettext gestolpert.
Mist, gettext habe ich mir auch schonn mal angeguckt, es dann aber wieder bleiben lassen, weil es kompliziert aussah.
Dann habe ich mir eben nur solche Tutorials angeschaut, die die von mir beschriebenen Nachteile haben - und wohl eher für kleine Seiten geeignet sind.
Ich werde mir das nach dem Urlaub auf jeden Fall mal ansehen - danke!
Gruß
Alex
-
-
Was haltet ihr davon?
Schlechte Idee - bei einer Tippfehlerkorrektur musst du dann mindestens 2 Stellen angreifen.
Das Übersetzungsfile und die Stelle(n) wo der aufruf darauf erfolgt.
Am übersichtlichsten wäre es sicher, die Wörter/Texte in einer DB zu speichern und für jeder Sprache eine Spalte zu haben.
Sehr unkluge Idee, wenn du beim hinzufügen einer Sprache ein Feld ergänzen musst, hast du beim normalisieren des Datenmodells einen Fehler gemacht.
Wenn jetzt aber für jeden Begriff der auftaucht die DB angeworfen werden muss, ist das sicher lästig für die.
Datenbanken sind recht gut dafür geeignet, große Textmengen zu durchsuchen - ob du jetzt die "Datenbank" anwirst oder einen XML-Parser der ein XML--File durchforstet ist egal - bei großprojekten mit wirklich vielen Zugriffen ist die Datenbank aber vermutlich eine Bremse. Solche Sachen löst man aber idR. durch ein Caching-System.
Ich hab mir überlegt, das ganze in der DB zu organisieren.
XML ist dafür imho wesentlich besser geeignet - vor allem, wenn man bedenkt, dass dir vermutlich für ein Caching-System ebenfalls das Know-How fehlt, wenn dir schon dir Normalisierung der Datenstruktur ein Problem bereitet.
Anschließend wird dann aus dem DB-Inhalt (bei jeder Änderung) eine statische PHP-Include-Datei generiert, wo die Daten in einen Array kommen (oder in ein Textfile).
Da kannst du gleich wieder Textfiles nehmen :)
Die beiden Threads könnten dich auch interessieren:
http://forum.de.selfhtml.org/archiv/2011/7/t205748/
http://forum.de.selfhtml.org/archiv/2011/2/t203078/-
Hallo,
Schlechte Idee - bei einer Tippfehlerkorrektur musst du dann mindestens 2 Stellen angreifen.
Das Übersetzungsfile und die Stelle(n) wo der aufruf darauf erfolgt.
»»
Das ist klar. Wie gesagt, erscheint mir die andere Lösung wie ich sie angesprochen habe sehr unübersichtlich. Genau aus diesem Grund mochte ich die Hauptsprache 1:1 in dem Skript haben. (Gut wäre auch, wenn der PHP-Editor die Keys (z.B. 'error_username' oder so) irgendwie mit dem Sprachfile verlinken würde - dann wäre es ja wieder übersichtlicher. Kennst du einen, der das kann?Ansonsten ist es mir dieser Nachteil aufgrund der Vorteile schon wert. Vor allem, da durch die Fehlermeldungen an mich ja auch nichts verloren gehen kann.
Am übersichtlichsten wäre es sicher, die Wörter/Texte in einer DB zu speichern und für jeder Sprache eine Spalte zu haben.
Sehr unkluge Idee, wenn du beim hinzufügen einer Sprache ein Feld ergänzen musst, hast du beim normalisieren des Datenmodells einen Fehler gemacht.
Ich würde nicht sagen, dass ich der absolute Datenbank-Profi bin, aber doch, dass ich mich in dem Bereich recht gut auskenne. Ich sehe da kein Problem mit der Normalisierung. Klär mich bitte auf, was du meinst.
Es gibt z.B. ID | DE | EN
Wenn ich jetzt noch Französisch hinzufügen will, mache ich ne neue Spalte FR rein. Da steht dann bei den derzeitigen Einträgen erstmal überall NULL.Dann kann ich nach und nach die Felder der FR-Spalte füllen.
Wo ist da das Normalisierungsproblem?
Ich hab mir überlegt, das ganze in der DB zu organisieren.
XML ist dafür imho wesentlich besser geeignet - vor allem, wenn man bedenkt, dass dir vermutlich für ein Caching-System ebenfalls das Know-How fehlt, wenn dir schon dir Normalisierung der Datenstruktur ein Problem bereitet.
So problematisch ist es sicher nicht. Ich finde es aber wie gesagt in einer Tabelle übersichtlicher als in einer anderen Form. Aber evtl. kann man ja ein XML daraus generieren.
Anschließend wird dann aus dem DB-Inhalt (bei jeder Änderung) eine statische PHP-Include-Datei generiert, wo die Daten in einen Array kommen (oder in ein Textfile).
Da kannst du gleich wieder Textfiles nehmen :)
Genau das will ich ja aufgrund der Übersichtlichkeit vermeiden. Wenn man sich die MySQL-Tabelle in Tabellenform anschaut und so bearbeitet, ist es sehr übersichtlich und man muss sich nicht durch andere Files wühlen.
Klar kann man diese Tabellenansicht und Änderbarkeit auch hinbekommen, wenn man die Textfiles enstprechend ausliest und im Browser darstellen lässt. Aber bei MySQL mit phpmyadmin ist das halt nicht nötig. Dann muss man nur noch - wenn man nicht direkt aus der DB lesen will - nachher ein File im entsprechenden Format erstellen.
Die beiden Threads könnten dich auch interessieren:
http://forum.de.selfhtml.org/archiv/2011/7/t205748/
http://forum.de.selfhtml.org/archiv/2011/2/t203078/Kenne ich schon, aber danke.
Gruß
alex
-
Es gibt z.B. ID | DE | EN
Wenn ich jetzt noch Französisch hinzufügen will, mache ich ne neue Spalte FR rein. Da steht dann bei den derzeitigen Einträgen erstmal überall NULL.
Was machst du, wenn du jetzt nicht nur 2 Sprachen hast sondern 48? Richtig, must die Struktur der Datenbank ändern.
Dann kann ich nach und nach die Felder der FR-Spalte füllen.
Wenn du bei der Erweiterung von Inhalte die Datenstruktur änderst, ist etwas falsch gelaufen.
Wo ist da das Normalisierungsproblem?
Das ist der Fehler und widerspricht der 1. Normalform:
http://databases.about.com/od/specificproducts/a/firstnormalform.htmIn dem Beispiel entspricht "Manager" deiner ID, und "Subordinate n" der Sprache.
So problematisch ist es sicher nicht. Ich finde es aber wie gesagt in einer Tabelle übersichtlicher als in einer anderen Form. Aber evtl. kann man ja ein XML daraus generieren.
Das ist nur eine Form der Darstellung - du kannst dir ein XML-File in Excel auch als Tabelle darstellen lassen - genau so wie du es beschrieben hast.
bezeichner | sprache1 | sprache2 |sprache n
Das kannst du dann bearbeiten, die eigentliche Datenstruktur ist aber sauber normalisiert.
Genau das will ich ja aufgrund der Übersichtlichkeit vermeiden. Wenn man sich die MySQL-Tabelle in Tabellenform anschaut und so bearbeitet, ist es sehr übersichtlich und man muss sich nicht durch andere Files wühlen.
Das liegt daran, dass du deine Kenntnisse bez. Datenbank vielleicht doch etwas überschätzt - wie daten Angezeigt werden und wie sie tatsächlich (sinnvoll) abgelegt werden, ist ein haushoher Unterschied.
Dann muss man nur noch - wenn man nicht direkt aus der DB lesen will - nachher ein File im entsprechenden Format erstellen.
Warum dann nicht gleich mit einem File arbeiten?
-
Hallo,
Was machst du, wenn du jetzt nicht nur 2 Sprachen hast sondern 48? Richtig, must die Struktur der Datenbank ändern.
Ich muss eine neue Spalte einfügen. Das ist dem Rest der Tabelle/Einträge vöölig egal.
Dann kann ich nach und nach die Felder der FR-Spalte füllen.
Wenn du bei der Erweiterung von Inhalte die Datenstruktur änderst, ist etwas falsch gelaufen.
Warum?
Wo ist da das Normalisierungsproblem?
Das ist der Fehler und widerspricht der 1. Normalform:
http://databases.about.com/od/specificproducts/a/firstnormalform.htmIn dem Beispiel entspricht "Manager" deiner ID, und "Subordinate n" der Sprache.
Ich sehe das Problem immer noch nicht. Für jede Phrase gibt es genau eine Zeile in der Tabelle. Mit anderen Tabellen oder anderen Zeilen in der Tabelle ist diese in keiner Weise verknüpft.
Bitte verlinke nicht irgendwelche Artikel, die mit diesem Problem nichts zu tun haben, sondern schreib doch einfach was du denkst. Ich sehe da kein Problem.
Das ist nur eine Form der Darstellung - du kannst dir ein XML-File in Excel auch als Tabelle darstellen lassen - genau so wie du es beschrieben hast.
bezeichner | sprache1 | sprache2 |sprache n
Das kannst du dann bearbeiten, die eigentliche Datenstruktur ist aber sauber normalisiert.
Das was du da als sauber normalisiert bezeichnest entspricht doch genau der von mir vorgeschlagenen Struktur, die du nicht sauber findest. Wie kann man das verstehen?
Das liegt daran, dass du deine Kenntnisse bez. Datenbank vielleicht doch etwas überschätzt - wie daten Angezeigt werden und wie sie tatsächlich (sinnvoll) abgelegt werden, ist ein haushoher Unterschied.
Wenn du das meinst. Ich denke nicht. (Bin übrigens nicht der "Alex" der neuerdings mit vielen Anfängerfragen kommt)
Dann muss man nur noch - wenn man nicht direkt aus der DB lesen will - nachher ein File im entsprechenden Format erstellen.
Warum dann nicht gleich mit einem File arbeiten?
Das habe ich denke ich schon zur Genüge erklärt - aber ja, der weg über XML mit Excel scheint auch gut zu sein.
Gruß
Alex-
Hi,
Bitte verlinke nicht irgendwelche Artikel, die mit diesem Problem nichts zu tun haben, sondern schreib doch einfach was du denkst. Ich sehe da kein Problem.
Da ich von dir eine Erklärung fordere, schulde ich dir glaube ich auch eine:
Also. Wir können uns glaube ich einig sein, dass der schlimmere Fehler und der hinderlichste Fehler der ist, dass man die Subordindates (aus deinem Beispiel) beim Manager in eine Spalte kommagetrennt reinschreibt.
Subordniate 1 | S... 2 | S.... 3 ist im Prinzip kein Fehler. Es ist dann nur schwieriger auf Veränderungen zu reagieren, aber man kann mit der DB doch noch gut arbeiten.
Vor allem bei so Sachen wie Manager Subordinate kann es aber schon Problemchen geben, auf die man dann im Code reagieren müsste. Wenn mal ein Subordinate wegfällt oder so. Man muss den Code auch anpassen, wenn mal ein fünfter dazukommt und man die DB angepasst hat.
Aber hier ist es schon was anderes. Ein extra Subordinate kommt in eine Firma schnell mal rein, wenn ein Boss sich das wünscht. Dann ändert sich nichts, bis auf dass bei einem Boss ein Sub mehr ist.
Eine komplette Website (großes Projekt) in einer weiteren Sprache anzubieten ist da was ganz anderes. Da wird jeder Sprach-Datenbankeintrag angefasst. Also zu jeder Phrase muss eine neue Sprache hinzukommen. Im Code kann man darauf auch vorher schon reagieren indem man die Verfügbaren Sprachspalten abruft und dann schaut ob man sie auslesen muss. (wenn man direkt aus der DB arbeitet beim erstellen der Seiten)
Also ich sehe da - auch wenns auf den ersten Blick ähnlich zu deinem Beispiel ist - himmelweite Unterschiede, die auch so eine Struktur hier rechtfertigen.
Gruß
Alex-
Subordniate 1 | S... 2 | S.... 3 ist im Prinzip kein Fehler. Es ist dann nur schwieriger auf Veränderungen zu reagieren, aber man kann mit der DB doch noch gut arbeiten.
Das maß der Dinge ist nicht, wie du damit arbeiten kannst sondern wie die Datenbank damit arbeitet - sobald du anfängst, felder mit "inhalt1, inhalt2" oder ähnliches zu benennen, läuft etwas falsch - ganz egal ob du als Mensch damit arbeiten kannst.
RDBMS sind dafür ausgelegt mit Relationen und verknüpften Tabellen zu arbeiten - Redundanzen in der Datenstruktur sind uncool.
Vor allem bei so Sachen wie Manager Subordinate kann es aber schon Problemchen geben, auf die man dann im Code reagieren müsste. Wenn mal ein Subordinate wegfällt oder so. Man muss den Code auch anpassen, wenn mal ein fünfter dazukommt und man die DB angepasst hat.
Dasselbe gibt für eine Sprache, wenn du plötzlich 7 statt 8 Sprachen hast - oder wenn eine Sprache nicht vollständig übersetzt ist - da hast du lauter Löcher, in denen sich das DMBS "NULL"-werte oder Leerstrings merken muss. Ordentlich normalisert gibts einfach keine Datensätze.
Aber hier ist es schon was anderes. Ein extra Subordinate kommt in eine Firma schnell mal rein, wenn ein Boss sich das wünscht. Dann ändert sich nichts, bis auf dass bei einem Boss ein Sub mehr ist.
Eine komplette Website (großes Projekt) in einer weiteren Sprache anzubieten ist da was ganz anderes.
Nein, ist es aus Sicht des Datenmodells nicht :) ich hab' Websites, da kommen öfter Sprachen dazu als die Firma/das Hotel neue Angestellte bekommt :)
Da wird jeder Sprach-Datenbankeintrag angefasst. Also zu jeder Phrase muss eine neue Sprache hinzukommen.
Nein, auch das ist oft nicht der Fall - oft wird nur das nötigste übersetzt, der rest wird mit Englisch als Fallback ausgeliefert.
Auch kann es sein, dass in einer Sprache später ein Teil dazukommt, der Rest aber erst später (oder gar nie) übersetzt wird - dann wären bei deinem Modell "Löcher" drin - und spätestens sowas ist ein Indiz für ein schlechtes Datenmodell.
Also ich sehe da - auch wenns auf den ersten Blick ähnlich zu deinem Beispiel ist
Es ist nicht ähnlich, es ist exakt dasselbe - das _ist_ die 1. Normalform :)
-
Hi,
RDBMS sind dafür ausgelegt mit Relationen und verknüpften Tabellen zu arbeiten - Redundanzen in der Datenstruktur sind uncool.
Wo ist da was redundant?
Dasselbe gibt für eine Sprache, wenn du plötzlich 7 statt 8 Sprachen hast - oder wenn eine Sprache nicht vollständig übersetzt ist - da hast du lauter Löcher, in denen sich das DMBS "NULL"-werte oder Leerstrings merken muss. Ordentlich normalisert gibts einfach keine Datensätze.
Eine solche Situation sehe ich, wie schon gesagt, als Fehler. Es ist also Ziel, alle Felder zu füllen.
Nein, ist es aus Sicht des Datenmodells nicht :) ich hab' Websites, da kommen öfter Sprachen dazu als die Firma/das Hotel neue Angestellte bekommt :)
Echt? Gerade im Tourismusbereich gibt es doch eine hohe Fluktuation, oder nicht? Irgendwann gehen dir die Sprachen aus, dann können nur noch neue Leute kommen :P
Da wird jeder Sprach-Datenbankeintrag angefasst. Also zu jeder Phrase muss eine neue Sprache hinzukommen.
Nein, auch das ist oft nicht der Fall - oft wird nur das nötigste übersetzt, der rest wird mit Englisch als Fallback ausgeliefert.
Das kommt in meinem Fall absolut nicht in Frage - s. oben: es ist für mich ein "Fehler". Schon rein rechtlich ist das problematisch, da auf diese Seite Verträge geschlossen werden sollen. Aber auch ansonsten finde ich eine unvollkommene Sprachgestaltung wiederlich.
Auch kann es sein, dass in einer Sprache später ein Teil dazukommt, der Rest aber erst später (oder gar nie) übersetzt wird - dann wären bei deinem Modell "Löcher" drin - und spätestens sowas ist ein Indiz für ein schlechtes Datenmodell.
S. oben: Nein
-
Hi,
RDBMS sind dafür ausgelegt mit Relationen und verknüpften Tabellen zu arbeiten - Redundanzen in der Datenstruktur sind uncool.
Wo ist da was redundant?
Dasselbe gibt für eine Sprache, wenn du plötzlich 7 statt 8 Sprachen hast - oder wenn eine Sprache nicht vollständig übersetzt ist - da hast du lauter Löcher, in denen sich das DMBS "NULL"-werte oder Leerstrings merken muss. Ordentlich normalisert gibts einfach keine Datensätze.
Eine solche Situation sehe ich, wie schon gesagt, als Fehler. Es ist also Ziel, alle Felder zu füllen.
Sicher? Was ist, wenn du eine Deutschsprachige Website hast, die plätzlich ihn landessprachenspezifische Varianten geteilt werden soll?
In der österreichischen Konfiguration befüllst du den String für den ersten Monat mit "Jänner" und den String für Tomaten mit "Paradeiser" - den rest musst du nicht ausfüllen.
Bei der Schweizer-Variante packst du bei Möhre ein "Rübli" rein und gut ist. Warum solltest du alles übersetzen?
Dasselbe gilt auch für Anglizismen, die in Vielen Sprachen einfach so verwandt werden.
Echt? Gerade im Tourismusbereich gibt es doch eine hohe Fluktuation, oder nicht? Irgendwann gehen dir die Sprachen aus, dann können nur noch neue Leute kommen :P
Ja, bei den Kellnern und Zimmermädchen - aber die "wichtigen Leute" wechseln nicht wie die Unterhose.
Das kommt in meinem Fall absolut nicht in Frage - s. oben: es ist für mich ein "Fehler". Schon rein rechtlich ist das problematisch, da auf diese Seite Verträge geschlossen werden sollen. Aber auch ansonsten finde ich eine unvollkommene Sprachgestaltung wiederlich.
Wenn bestimmte Bereiche in einer Sprache garnicht existieren, muss man sie auch nicht übersetzen :) aber das ist natürlich eine konzeptionelle Sache - aber auch das hat nichts mit dem Datenmodell zu tun.
Auch kann es sein, dass in einer Sprache später ein Teil dazukommt, der Rest aber erst später (oder gar nie) übersetzt wird - dann wären bei deinem Modell "Löcher" drin - und spätestens sowas ist ein Indiz für ein schlechtes Datenmodell.
S. oben: Nein
Siehe oben: Regionalsprachen sind so ein Fall, wo es absurd ist, alles zu übersetzen. amerikanisches Englisch, britisches Englisch, australisches Englisch - da gibts nicht viele unterschiede, warum also alles "Übersetzen"?
-
-
-
-
Was machst du, wenn du jetzt nicht nur 2 Sprachen hast sondern 48? Richtig, must die Struktur der Datenbank ändern.
Ich muss eine neue Spalte einfügen. Das ist dem Rest der Tabelle/Einträge vöölig egal.
Dem Datenmodell aber nicht.
Warum?
Du nimmst relationalen Datenbank ihren essentiellen Vorteil: Eliminierung von Problemen, die bei 2-dimensionalen Datenstrukturen auftreten.
bezeichner | sprache1 | sprache2 |sprache n
Das kannst du dann bearbeiten, die eigentliche Datenstruktur ist aber sauber normalisiert.
Das was du da als sauber normalisiert bezeichnest entspricht doch genau der von mir vorgeschlagenen Struktur, die du nicht sauber findest. Wie kann man das verstehen?
Nein, lies es nochmal - das Beispiel ist lediglich der View für den Menschen, nicht aber die dahinterliegende Datenstruktur.
Wenn du das meinst. Ich denke nicht. (Bin übrigens nicht der "Alex" der neuerdings mit vielen Anfängerfragen kommt)
Das ist mir egal :)
Das habe ich denke ich schon zur Genüge erklärt - aber ja, der weg über XML mit Excel scheint auch gut zu sein.
Ob du jetzt ein XML mit sauberer Struktur in Excel so darstellst, dass ein Mensch Freude damit hat oder eine Sauber normaisierte relationale Datenbank hast, die bei der Ausgabe menschenlesbar wird, ist egal :)
-
Ich muss eine neue Spalte einfügen. Das ist dem Rest der Tabelle/Einträge vöölig egal.
Dem Datenmodell aber nicht.
Warum? Es juckt die anderen Spalten nicht im geringsten, wenn da noch eine Spalte dazukommt.
bezeichner | sprache1 | sprache2 |sprache n
Das kannst du dann bearbeiten, die eigentliche Datenstruktur ist aber sauber normalisiert.
Das was du da als sauber normalisiert bezeichnest entspricht doch genau der von mir vorgeschlagenen Struktur, die du nicht sauber findest. Wie kann man das verstehen?
Nein, lies es nochmal - das Beispiel ist lediglich der View für den Menschen, nicht aber die dahinterliegende Datenstruktur.
Das musst du schon dazusagen, wie du es verstehst. Ansonsten sah es nämlich genau so aus wie meine Struktur.
Wie würdest du es denn machen?
Bezeichne | Sprachcode | Text
Beispiel:
error_username | DE | Ihr Username ist leider schon vergeben
error_username | EN | Sorry, your username is already takenSo?
Mit diesen "Bezeichnern" wird das dann in der Tat gut klappen. Aber wie gesagt will ich das aus gutem Grund nicht. (Außer ich finde einen PHP-Editor, der die NAchteile eliminieren kann.)
Wenn ich es so mache kommen nämnlich dann bei meiner VErsion (kein Bezeichner sondern nur die tatsächlichen Strings) tatsächlich redundanzen. DAnn muss man für jedes Komma das man im deutschen Text ändert alle "Bezeichner" (die ja bei mir den ganzen Text darstellen würden) ändern oder man bekommt Probleme.
In meiner Variante hat man diese Probleme nicht, weil jede Zeile der DB von allen anderen Zeilen völlig unabhängig ist und man also immer nur 1 Zeile ändern muss.
Das habe ich denke ich schon zur Genüge erklärt - aber ja, der weg über XML mit Excel scheint auch gut zu sein.
Ob du jetzt ein XML mit sauberer Struktur in Excel so darstellst, dass ein Mensch Freude damit hat oder eine Sauber normaisierte relationale Datenbank hast, die bei der Ausgabe menschenlesbar wird, ist egal :)
Sag ich ja ;)
-
Das musst du schon dazusagen, wie du es verstehst. Ansonsten sah es nämlich genau so aus wie meine Struktur.
Wie würdest du es denn machen?
Bezeichne | Sprachcode | Text
Beispiel:
error_username | DE | Ihr Username ist leider schon vergeben
error_username | EN | Sorry, your username is already takenSo?
Exakt.
Mit diesen "Bezeichnern" wird das dann in der Tat gut klappen. Aber wie gesagt will ich das aus gutem Grund nicht. (Außer ich finde einen PHP-Editor, der die NAchteile eliminieren kann.)
Das visuell in die von dir gewünschte Form zu bringen ist absolut keine Hexerei.
Wenn ich es so mache kommen nämnlich dann bei meiner VErsion (kein Bezeichner sondern nur die tatsächlichen Strings) tatsächlich redundanzen. DAnn muss man für jedes Komma das man im deutschen Text ändert alle "Bezeichner" (die ja bei mir den ganzen Text darstellen würden) ändern oder man bekommt Probleme.
Darum soll der Bezeichner auch nicht der klartext der defaultsprache sein - sobald du da einen Tippfehler hast, kannst du das ganze Sysem vergessen. Das ist auch einer der Nachteile von gettext()
In meiner Variante hat man diese Probleme nicht, weil jede Zeile der DB von allen anderen Zeilen völlig unabhängig ist und man also immer nur 1 Zeile ändern muss.
Eine einzige riesige 2-dimensionale Tabelle ist in relationalen Datenbanken defective by design - egal wie du es drehst und wendest :)
Sag ich ja ;)
Nein, du willst die Datenstruktur gleich Menschenlesbar haben, damit machst du aber die Datenhaltung kaputt.
In deinem Fall mag das sinnvoll erscheinen, aber jetzt stell dir mal einen Online-Shop vor, in dem die Artikel Attribute haben.
Größe und Farbe z.B. - gibts dann da bei jedem Artikel ein Feld "groesse" und "farbe" und wenn dann mal das Gewicht dazukommt, wird eine neue Spalte gemacht?
Natürlich gibt es Fälle, wo es absolut nicht gerechtfertig ist, alles tot zu normalisieren - aber im Kontext von Sprachen hast du einfach eine Dimension, die es gradezu erfordert. Zwei Sprachen erscheinen dir vielleicht noch übersichtlich - aber was ist mit 10, 25 oder 100 Sprachen?
Dein DBMS muss, auch wenn du die Feldliste einschränkst, sicher weniger freude damit haben. Zwar habe ich jetzt keine Daten dafür, aber ich stelle in dem Raum, dass eine Abfrage einer bestimmten Sprache aus dieser Struktur
bezeichner | sprache | wert
wesentlich schneller ist als aus dieser struktur
bezeichner | sprache1 | sprache| ... | sprache82
-
Hi,
Mit diesen "Bezeichnern" wird das dann in der Tat gut klappen. Aber wie gesagt will ich das aus gutem Grund nicht. (Außer ich finde einen PHP-Editor, der die NAchteile eliminieren kann.)
Das visuell in die von dir gewünschte Form zu bringen ist absolut keine Hexerei.
Mit welchem Editor machst du das? Mir geht es wie gesagt bei den "Bezeichnern" um das Problem, dass ich direkt im Quellcode der normalen Skripte nicht sehe, was genau hinter einem Bezeichner steht. Andersrum kann ich nicht wie gewohnt einfach drauflos schreiben, sondern muss einen Bezeihner wählen und dann nachher irgendwo den Klartext reinmachen.
Bei einem kleinen Projekt mag das ja kein Problem sein. Aber je größer es wird desto besser wäre hier eine einfache Lösung.
Wenn es also einen PHP Editor gibt, der diese Problematik entschärfen kann, indem er das Sprachfile beim Programmieren irgendwie verknüpft wäre das super.
Eine einzige riesige 2-dimensionale Tabelle ist in relationalen Datenbanken defective by design - egal wie du es drehst und wendest :)
Sag ich ja ;)
Nein, du willst die Datenstruktur gleich Menschenlesbar haben, damit machst du aber die Datenhaltung kaputt.
In deinem Fall mag das sinnvoll erscheinen, aber jetzt stell dir mal einen Online-Shop vor, in dem die Artikel Attribute haben.
Schau, in meinem Fall erscheint das sinnvoll ;) Sagen wir mal ich muss die Bezeichner im Klartext haben. Dann wären ja durch 1 Zeile/Sprache bei der Defaultsprache unendliche Redundanzen drinnen und einen Fehler müsste man in 100 Zeilen korrigieren ansonsten hat man nur noch Schrott.
Gut, das geht ja auch zu automatisieren, aber sauber ist das nicht. Deshalb denke ich, dass meine DAtenstruktur hier der einzig saubere Weg ist, um nämlich genau Redundanzen und Fehlerpotentiale auszuschließen.
Bei anderen Inhalten mache ich das natürlich nicht immer so. Da werden auch überall Redundanzen vermieden etc. z.B. durch eine Aufteilung auf 2 Tabellen oder Hilfstabellen etc.
Dein DBMS muss, auch wenn du die Feldliste einschränkst, sicher weniger freude damit haben. Zwar habe ich jetzt keine Daten dafür, aber ich stelle in dem Raum, dass eine Abfrage einer bestimmten Sprache aus dieser Struktur
bezeichner | sprache | wert
wesentlich schneller ist als aus dieser struktur
bezeichner | sprache1 | sprache| ... | sprache82
Das müsste man sich mal anschauen. Wie schon ganz am Anfang gesagt, halte ich es eh für suboptimal wirklich jeden Textbaustein einzeln aus der DB zu holen. Da käme man ja schnell auf 30 zusätzliche DB Abfragen pro Aufruf eine Seite.
Deshalb war ja meine Idee dann auch, bei einer DB-Änderung immer ein statisches File zu aktualisieren und die Sprache da reinzubauen. Die DB wäre dann nur ein Hilfsmittel. Gearbeitet würde mit dem unübersichtlichen Textfile durch PHP. Wenn man was ändern will kann man das (zumindest solange es noch wenige Sprachen sind) einfach über PHPmyadmin machen, ohnedafür auch noch etwas programmieren zu müssen.
Gruß
Alex-
Mit welchem Editor machst du das? Mir geht es wie gesagt bei den "Bezeichnern" um das Problem, dass ich direkt im Quellcode der normalen Skripte nicht sehe, was genau hinter einem Bezeichner steht. Andersrum kann ich nicht wie gewohnt einfach drauflos schreiben, sondern muss einen Bezeihner wählen und dann nachher irgendwo den Klartext reinmachen.
Achso - du bist noch bei diesem Thema - ich dachte, das wäre längst vom Tisch. Dafür ist die Lösung nur "suchen und ersetzen", wirft aber die bereits genannten Probleme mit mehrdeutigen Übersetzungen auf.
Bei einem kleinen Projekt mag das ja kein Problem sein. Aber je größer es wird desto besser wäre hier eine einfache Lösung.
Gerade bei größeren Projekten eben nicht - da sind so viele Menschen beteiligt, dass eine modulare Lösung die einzig sinnvolle ist - in der Praxis hast du nie sofort eine vollständige Übersetzung einer neuen Sprache.
Schau, in meinem Fall erscheint das sinnvoll ;) Sagen wir mal ich muss die Bezeichner im Klartext haben. Dann wären ja durch 1 Zeile/Sprache bei der Defaultsprache unendliche Redundanzen drinnen und einen Fehler müsste man in 100 Zeilen korrigieren ansonsten hat man nur noch Schrott.
Wenn dein Bezeichner tatsächlich verwandt wird, müsste man auch das auch nicht, wenn man das über eine Beziehung innerhalb der Tabelle löst.
id | string | lang | parent
---+---------+------+----------
1 | blau | de |
2 | blue | en | 1
3 | bleu | fr | 1Wenn sich "blau" aber jetzt ändern, musst du trotzdem an allen Stellen wo blau vorkommt, das "blau" anpassen - das ist uncool - darum sollte es _immer_ zusätzlich einen Bezeichner geben - und natürlich kannst du auch den normalisieren, wobei das etwas überflüssig ist, da unveränderlich sein sollte
Egal wie du es drehst und wendest, dein Fall ist nicht so besonders, dass er eine schlechte Datenstruktur rechtfertigt :)
Gut, das geht ja auch zu automatisieren, aber sauber ist das nicht. Deshalb denke ich, dass meine DAtenstruktur hier der einzig saubere Weg ist, um nämlich genau Redundanzen und Fehlerpotentiale auszuschließen.
Eine saubere Datenstruktur ist _immer_ der richtige Weg um Redundanzen und Fehler zu vermeiden. Mit Müllcode passiert sowas viel leichter.
Das müsste man sich mal anschauen. Wie schon ganz am Anfang gesagt, halte ich es eh für suboptimal wirklich jeden Textbaustein einzeln aus der DB zu holen. Da käme man ja schnell auf 30 zusätzliche DB Abfragen pro Aufruf eine Seite.
Das sagte ich bereits, dass du das Cachen sollst oder gleich eine Datenstruktur trotzdem rechtfertigt auch das keine schlechte Datenstruktur :)
Deshalb war ja meine Idee dann auch, bei einer DB-Änderung immer ein statisches File zu aktualisieren und die Sprache da reinzubauen. Die DB wäre dann nur ein Hilfsmittel. Gearbeitet würde mit dem unübersichtlichen Textfile durch PHP. Wenn man was ändern will kann man das (zumindest solange es noch wenige Sprachen sind) einfach über PHPmyadmin machen, ohnedafür auch noch etwas programmieren zu müssen.
In diesem fall kannst du dann eben gleich eine Speicherlösung suchen, die kein umständliches Caching braucht und sich schnell lesen lässt - und da kommt eben wieder XML ins Spiel, welches du mit sauberer Struktur dann mittels XML trotzdem in dieser mehrspalten-Ansicht darstellen kannst.
-
-
-
-
-
-
-
-
-
Hoi,
Also Thema 1. Du hast immer noch einen Key welchen du dir merken musst. Nur ist er viel länger und eben ein Satz.
Was zudem recht schlecht ist, dass ist die Verteilung von dem ganzen im kompletten Quellcode. Wenn dein Projekt sagen wir mal 50 Dateien beinhaltet (und das ist noch human), dann sag mir in 6 Monaten mal aus welcher Datei der Fehler "Fehler: Falsche Userangabe" kommt. Na klar man kann die Dateien durchsuchen. Besser wäre jedoch eine Zentrale stelle.
Noch besser wäre eine Zentrale stelle welche durch einen nicht Sachkundigen Mitarbeiter bearbeitet werden kann. Sprich du hast ein Interface zu den Fehlermeldung setzt eine doofe Lektorin daran und die könnte dir alles übersetzen oder in einem guten Deutsch formulieren.Thema 2.
Theoretisch eine gute Idee, da muss man aber das pragmatische sehen. Wenn du für jeden Poppel eine Datenbank abfrage startest ist eine Auslagerung in eine statische PHP Datei das richtige. Wenn du hingegen nur die Fehler ausgibst (und da sollten jetzt nicht so viele pro Webseite vorkommen), dann reicht der simple Weg über die Datenbank.Nochmal zum Thema 1:
meine Mehrsprachige Tabelle hat folgende Felder:
Code, CodeNr, Sprache, Text, Type, MailDer Code ist unique, so wie die Codenr. Der code lautet z.B. "ERROR_LOGIN_USER_NAME". Der wird im Quellcode benutzt. Die Codenummer wird nur zur Vollständigkeit mitgeschleift. Falls später ein Exception Cache steht, werde ich über die Codenr schneller den entsprechenden Text finden. Sprache ist klar, text auch. Type beinhaltet 3 Typen, Error(0), Success(1) und Warning(2). Dann kann man Meldungen auf gut und böse unterscheiden und eventuell entsprechend Exception schmeißen. E-Mail enthält eine E-Mail an die eine Meldung gesendet wird, falls diese Meldung ausgegeben. Das wird meistens im krassen Fehlerfall sein, falls jemand versucht dein System zu hacken. Könnte theoretisch aber auch bei guten Sachen passieren, falls sich jemand erfolgreich neu registriert hat.
Gruß
Mehrsprachiger
T-Rex-
Hi,
danke für deine ausführliche Antwort!
Ich glaube wir haben uns ein bisschen missverstanden. Mit der Fehlermeldung meine ich nicht die Art Fehlermeldung die du meinst - also einen "sonstigen Programmfehler" oder Hackingversuch.
Ich meine vielmehr den Fehler, dass das Äquivalent zur gesuchten Phrase in der Zielsprache nicht gefunden wurde. Hierüber soll dann ich oder der Übersetzer informiert werden.
Also z.B.:
Ich baue ein neues Formularfeld ein. Das soll das Label "Geburtsdatum" haben. Mit lang("Geburtsdatum") gebe ich das dann ein. So habe ich für meine ganze Test/Programmierphase schon sofort, ohne in ein Sprachfile zu gehen und etwas einzutragen in dem Formular "Geburtsdatum" stehen, weil es bei DE ja ohnehin einfach $text ausgibt.Gleichzeitig guckt die Funktion aber, ob "Geburtsdatum" in der Sprachdatei ist und in allen Sprachen vorhanden ist. Wenn das nicht der Fall ist kommt meine "Fehlermeldung". Ich werde dann also aufgefrodert den Begriff zu übersetzen.
Das kann ich dann irgendwann wenn ich Lust habe abarbeiten.
Also Thema 1. Du hast immer noch einen Key welchen du dir merken musst. Nur ist er viel länger und eben ein Satz.
Ich glaube vor dem Hintergrund, wie ich ihn oben erläutert habe, sollte das jetzt kein Problem mehr sein, oder?
Was zudem recht schlecht ist, dass ist die Verteilung von dem ganzen im kompletten Quellcode. Wenn dein Projekt sagen wir mal 50 Dateien beinhaltet (und das ist noch human), dann sag mir in 6 Monaten mal aus welcher Datei der Fehler "Fehler: Falsche Userangabe" kommt. Na klar man kann die Dateien durchsuchen. Besser wäre jedoch eine Zentrale stelle.
50 Dateien wäre schön ;) Es sind doch deutlich mehr.
Manchmal gibt es vielleicht Situationen in denen der Kontext wichtig ist. Vielleicht wäre da noch ein Parameter in lang() sinnvoll. Aber normalerweise interessiert das ja nicht. Wenn eine Fehlermeldung oder ein Hinweistext an den User ausgegeben werden soll, soll der eben ausgegeben werden. Das was da steht muss dann in die Sprachen übersetzt werden und ist ja zumeist unabhängig vom Kontext.
Aber vielleicht beruht das auch noch auf dem Missverständnis mit den Fehlermeldungen^^
Noch besser wäre eine Zentrale stelle welche durch einen nicht Sachkundigen Mitarbeiter bearbeitet werden kann. Sprich du hast ein Interface zu den Fehlermeldung setzt eine doofe Lektorin daran und die könnte dir alles übersetzen oder in einem guten Deutsch formulieren.
Stimmt, "meine Fehlermeldungen" könnten dann ja direkt in eine To-Do-List für einen Übersetzer wandern, die er einfach abarbeiten kann.
Gruß
Alex
-
-
Hi,
Es geht vor allem um winzige bis mittlere Textpassagen. Also von einzelnen Wörtern (z.B. Labels in einem Formular) bis zu ein paar Sätzen (Fehlermeldungen, Hinweis-/Hilfetexte etc.)
Da wird ja glaube ich meistens eine Lösung vorgeschlagen, dass man irgendwo in einem Array oder sonstwo die Texte speichert und sie z.B. über $lang['error_username'] ausgibt. Im Array wäre dann z.B. "Fehler: Sie haben einen falschen Usernamen eingegeben!" gespeichert.Das ist mir irgendwie zu umständlich, weil ich dann immer die Array-Keys ('error_username') im Kopf haben muss bzw. immer hin und her gucken muss, was was bedeutet.
Wenn ich z.B. eine Fehlermeldung habe, gebe ich sie so aus:
echo lang("Fehler: Sie haben einen falschen Usernamen eingegeben!");Die Funktion guckt dann erstmal, welche Sprache die richtige ist. (Dazu habe ich mal für ein Uni-Projekt eine hübsche - und ich hoffe, gute - Language Negotiation gemacht. Aber das ist ein anderes Thema).
Wenn DE die Zielsprache ist, gibt die Funktion einfach $text zurück, so wies reinkam.
Schlechte Idee, weil Wörter mehrere Übersetzungen haben können, je nach Zusammenhang.
z.B. kann die Übersetzung für "Kette" in die englische Sprache mal "chain" oder "necklace" oder "linkage" oder "string" oder ... sein.
Oder umgekehrt, "line" kann mal "Linie" und mal "Zeile" oder auch "Strecke" oder sein.Wenn man vom konkreten Text unabhängige Schlüssel verwendet, kann man auch für mehrere Wortbedeutungen die passenden Übersetzungen angeben (indem man als Schlüssel z.B. 'kette_halskette' verwendet und dafür dann deutsch 'Kette' und englisch 'necklace' hinterlegt), wenn aber das Wort aus Sprache 1 der Schlüssel sein soll, hat man bei mehrdeutigen Wörtern ein Problem ...
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Hi,
Schlechte Idee, weil Wörter mehrere Übersetzungen haben können, je nach Zusammenhang.
z.B. kann die Übersetzung für "Kette" in die englische Sprache mal "chain" oder "necklace" oder "linkage" oder "string" oder ... sein.
Oder umgekehrt, "line" kann mal "Linie" und mal "Zeile" oder auch "Strecke" oder sein.Wenn man vom konkreten Text unabhängige Schlüssel verwendet, kann man auch für mehrere Wortbedeutungen die passenden Übersetzungen angeben (indem man als Schlüssel z.B. 'kette_halskette' verwendet und dafür dann deutsch 'Kette' und englisch 'necklace' hinterlegt), wenn aber das Wort aus Sprache 1 der Schlüssel sein soll, hat man bei mehrdeutigen Wörtern ein Problem ...
Stimmt, das könnte zum Problem werden, wenn es solche Begriffe gibt. Muss ich mal durchgucken...
Gruß
Alex-
Hi,
Stimmt, das könnte zum Problem werden, wenn es solche Begriffe gibt. Muss ich mal durchgucken...
Vergiß beim Durchgucken aber nicht das Durchsuchen der Begriffe, die Du irgendwann in der Zukunft mal brauchen wirst ...
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
-