Sprachverwaltungs-System für WebApp

[Dieter Raber]

Hallo Lupus,

bin ich ja froh, wenn du weiterkommst.

Da möchte ich mir natürlich keine falschen, schlechte oder halbpatzige Techniken aneignen.

Das ist immer schon mal eine sehr gute Idee

Ich verstehe aber nicht ganz, was der Vorteil ist, wenn ich das Vokabular in in einer INI-Datei festlege. Ganz einfach, ich mag INI-Dateien, die sind leicht zu warten. Zudem kann man die meist auch Programmier-Laien anvertrauen, zB. dem Uebersetungsbuero.

Die Zeit, die parse_ini_file() verwendet, kannst du bei diese Groesenordnung getrost vergessen.

Was deine Frage mit dem Umweg ueber die Datenbank angeht, das hat mehr organisatorische Gruende. Das kannst anhand unseres Workflows sehen:

• Die DB liegt auf einem zentralen Server, auf den die meisten Kollegen Zugriff hat. Dort werden aber nur Standardfloskeln verwaltetet. Ich mache jetzt einen neuen Eintrag in Deutsch und Englisch. Danach nimmt sich zB. die franzoesische Praktikantin die fehlenden Uebersetungen vor.
• Jede Nacht wird das gesamte Framework aus dem SVN exportiert, danach werden die locale-files aus der DB generiert
• Wenn jetzt ein Programmierer ein neues Projekt anfaengt, hat er eine aktuelle Kopie des Frameworks mit aktuellem (Standard-)Vokabular.
• Zu jedem Projekt gehoeren aber noch andere, projektspezifische, Ubersetzungsdateien. Die werden erstmal von Hand geschrieben. I.d.R macht das jeder Progammierer in Englisch und seiner Muttersprache, d.h. hier muessen regelmaessig Abgleiche gemacht werden un das wiederum kann die Praktikantin machen.
• Die Uebersetzungsklasse nimmt sich jetzt alles mit parse_ini_file vor, was im Ordner /locale/fr (en/de...) liegt. Da hat es wenig Sinn zu sagen, nimm dieses und jenes aus der DB und alles andere aus Dateien.

Was die komplizierten Faelle angeht, bis jetzt konnte ich das mit sprintf ganz gut loesen. Fall das nicht klappen sollte, muesste ich mir auch erstmal eine Loesung zurechtzimmern.

Zu GET und SESSION
Wir machen unsere URIs so: server/locale/alles-andere und uebersetzen das mit mod_rewrite zu locale=de&path=alles-andere, das heisst, wir haben, ausser beim ersten Aufruf, immer ein GET-Parameter. Das ist auch eine ziemlich gaengige Praxis. Ich wuerde deine Selectform auch eher auf GET setzen, dann entfaellt der laestige Post-Hinweis beim zurueckblaettern. Und beim naechsten Projet wird es garantiert irgendwie anders sein, weil dem Designer oder dem Kunden irgendwas zum Thema einfallen wird... Na gut, du macht eine Schuelerprojekt, aber du hast ja, was den Stil angeht, offenbar gute Vorsaetze. Insofern wuerde ich an deiner Stelle das Problem ein fuer alle Male loesen und alle Moeglichkeiten der Locale-Uebergabe von vornherein implementieren. Du sprichst in deinem Posting mehrfach die Zeit an, die bestimmte Funktionalitaeten beanspruchen. Klar kosten zusaetzliche Checks Performance, aber das ist trivial, verglichen mit den zukuenftigen Problemen, die entstehen, wenn du solche Loesungen nicht konsequent durchprogarmmierst.

Gruss

Dieter