Idee zur Mehrsprachigkeit

[suit]

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   | 1

Wenn 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.