Übersetzungssystem eines CMS

[dragon001]

Wir sind gerade dabei unser CMS zu überarbeiten.
Da haben wir uns gefragt, wieso wir das Übersetzungssystem nicht auf Datenbank basis ansetzen.
Hätte den Vorteil das die Übersetzung zu Laufzeit nicht Wertvolle Recoursen belegt (ob Variablen, Arrays, Konstanten).
Es werden nur die Übersetzungen verarbeitet, die benötigt werden.

Einziger Hacken, mehr Datenbank zugriffe.
was halltet ihr davon?

 

[jan]

hi,

ich denke das das keinen Sinn macht. Die Übersetzungen eines CMS ändern sich nicht ständig, sondern nur bei Updates, und die Datenbankzugriffe könnten schon ziemlich aufhalten (Je nach Provider). Bei unserem http://www.redaxo.de CMS haben wir die Sprachdateien in eigene Dateien gelegt und je nach Sprache wird ein "Sprachenobjekt" generiert. Wir haben nur eine Sprachendatei pro Sprache, d.h. wenn eine neue Sprache entstehen soll, dann wird diese Datei kopiert und direkt übersetzt. Die Größe der Datei hat meines Erachtens nicht so viel Geschwindigkeitseinfluss wie die Aufrufe der Datenbank.

Ich hoffe ich konnte ein wenig helfen.

Lg

Jan

 

[server4downs]

Ich stimme auch deutlich für TXT!
Gründe sind vor allem die Geschwindigkeit. Heutzutage wird zu viel in die Datenbanken gestopft meines Erachtens.
Wenn sich etwas am CMS ändert, so müssen ja logischerweise sowieso Files bearbeitet werden, dann werden so ein paar language-lines den Kohl auch nicht mehr fett machen (obwohl der es ja schon ist ).

 

[dragon001]

mein System ist halt voll Modular aufgebaut.
Module werden dynamisch geladen über eine Datei etc.
Bisher war bei dem System, hatte es damals nicht anders gelöst, alles in
konstanten abgelegt.
Wollte ursprünglich auf Variablen umsteigen.
Jedoch, wenn man ca 500 - 600 Übersetzungsstrings nur für die Administration hat, wird der Arbeitsspeicher schnell überladen.
Zur Hintergrund Info => der Datenbank layer entstammt ursprünglich dem phpbb. Ist jedoch inzwischen auf adoDB umgestellt,
erweitert also inzwischen denn AdoDB layer. (mit Caching etc.)
Geschwindigkeitsmäßig liegt das System relativ weit vorne.
Werde es ab Juni auf einer Stark besuchten Seite (Community mit ca 300 fest angemeldeten Usern und ca 3000 Page Views pro Tag einfach mal testen lassen.
(Ist eh nur ein kleines System Update).

Der Vorteil an meinem Übersetzungssystem besteht darin, das ich ihn jederzeit auch auf txt oder sqlite umstellen kann.

 

[ElNino]

Werde es ab Juni auf einer Stark besuchten Seite (Community mit ca 300 fest angemeldeten Usern und ca 3000 Page Views pro Tag einfach mal testen lassen.

Ist das jetzt dein Ernst, oder ein Scherz?

Tom

 

[dragon001]

Ist das jetzt dein Ernst, oder ein Scherz?

Tom

Das ist eigentlich mein ernst!
Was ist daran auszusetzen?

 

[Sandmann]

Vergiss das mit der Datenbank. Mach halt nicht alles in eine Datei. Für jedes Modul eine eigene und schon hast es "performanter".

 

[dragon001]

Mag sein, doch mit der Datei hast du immer entweder viel Speicher mit Konstanten oder Variablen zugemüllt.
Der Test in einer meiner betreuten Communitys beginnt in Kürze.
Die Server verwenden alle MySQL 4 mit Query Cache.
Auf meinem eigenen Server passt die Performance.
Das ganze System wurde durch den eAccelerator gejagt und optimiert (als BitCode).
Das Zielsystem verwendet auch eAccelerator.
Also Performance mäßig passt es eigentlich.
Großteil der Übersetzung ist im Endeffekt für die Verwaltung vorgesehen.
Der Rest (ca 39%) ist bestandteil der Module.
Der Inhalt wird ja schließlich auch aus der Datenbank gelesen.
In Kürze werd ich den DB LAyer auf AdoDB umstellen mit Caching etc.
Mal auf die ersten Testergebnisse warten.

(ein ersten Burnin Test hatte ich mit einer Benchmark Software bereits getätigt.
Simultaner Zugriff von 50 Usern parrallel.
BanScript deaktiviert (Verbannt IPs die öffters innerhalb kürzester Zeit (2 Minuten) zugegriffen haben.)
)