Multilanguage

[Santer]

Hallo,

ich habe eine Frage. Zur Zeit arbeite ich an einer Seite für einen Kunden, die Multilanguage beherrschen soll.

Soweit ist alles okay.

Gibt es bessere Möglichkeiten, als Sprachdateien mit:

<?php

define ("XXX", "YYY");

usw.

?>

oder

<?php

$GLOBALS["XXX"] = "YYY";

?>

zu nutzen?

Ist es vorteilhaft mit einem array[] zu arbeiten oder eher nicht?

[Amstelchen]

meiner erfahrung und beobachtung in bezug auf möglichst modulare und wiederverwendbare scriptprogrammierung ist eine datei pro sprache bei vielen definitionen sinnvoll, andernfalls ein zweidimensionales array, aber nicht global. ich bin pers. gegen die verwendung von $GLOBALS, worin mich auch PHPit - Totally PHP Using globals in PHP bestärkt.

sieh dir "gute" PHP-applikationen an, die ML anbieten und schau, wie die das lösen.

s'Amstel

[Santer]

Temporär habe ich es über $GLOBALS eingebunden.

Jedoch bin ich auf so etwas gestoßen.

require_once("include/class_language.php");


$lang = new trackerlanguage;

$lang->set_path($rootpath . 'include/languages');

$lang->set_language(english);

[/PHP]

[PHP]
$lang->load('XXX'); // XXX replace with filename like "index".lang.php

$lang->file['var'] // Replace file with loading file like 'index' ...  and replace var with your created vars

[/PHP]

index.lang.php

[PHP]
<?php
// index.php //Filename

$language['index'] = array (
'xxx1' =>'yyy1',
'xxx2' =>'yyy2',

)
?>

Die class_language.php habe ich nicht mit angehängt.

Möglich ist es, dass weiß ich, denn so wird es im WBB verwendet. Nur ist es wirklich eine bessere Methode dies so einzubinden?

Ich persönlich mag es nicht mit " -> " zu arbeiten. Ich finde es sieht nicht gut aus!

[.vash]

naja ich denke der ästhetische Aspekt sollte hier im Hintergrund stehen.

Von globalen Variablen würde ich die Finger lassen. Entweder per Hand die Sprachdateien bearbeiten oder eine Datenbanklösung wählen (wobei hier bei großer last ein entsprechendes Caching mitarbeiten sollte)

[Santer]

Über eine Datenbanklösung habe ich am gestrigen Tag auch nachgedacht. Im Endeffekt wäre es ja nur ein query pro Seite mehr.

Die Seite müsste ca 15.000 - 20.000 Aufrufe anfangs abfangen können, daher wäre ein Caching sicherlich lohnenswert, da es ja statische Sachen sind, die sich nicht allzuviel verändern auch kein Problem.

Zur Zeit schweben mir da recht viele Sachen durch den Kopf.

Anzahl PHP-Dateien mit Textausgabe? ca. 200 Dateien (jeweils ca. 30 Texte)

Wiederholende Texte? insgesamt 30

Mir geht es im Endeffekt darum, welche Möglichkeit die wenigsten Auslastung verursacht und immer noch sehr schnell ist. Da die Seite nicht allzu lange laden soll.

Ich werde nachher mal schauen, wie es bei mir mit der Anzahl der Queries aussieht und wie schnell die Seiten sind.

Danke für die Beiträge

MFG

[gurkenpapst]

schon mal an smarty (Smarty : Template Engine ) gedacht?

hat ein brauchbares caching system, ist mächtig, trotzdem performant.

wie du die Multi Language Möglichkeiten umsetzt, ist per se nicht mit einem satz zu sagen, weil es verschiedene ansätze mit unterschiedlichen vor und nachteilen gibt. (z.B. config Dateien, unterschiedlich template-Verzeichnisse je Sprache...usw.)

[.vash]

Auch wenn eine strikte Trennung von Code und Logik sinnvoll erscheint, dann ist sie das meiner Meinung nach nur, wenn Programmierer und Designer weit weg voneinander sitzen.

Selbst in der Smartyeinleitung steht dass es dafür gedacht es wenn diese zwei Aufgaben von unterschiedlichen Personen wahrgenommen wird.

[gurkenpapst]

sehe das aber nicht als Grund es nicht für eine mehrsprachige Anwendung zu verwenden, geschweige denn jetzt hier zu ergründen, wann Trennung von Logik und UI sinnvoll ist (und eine mehrsprachige Anwendung IST für mich möglicherweise, je nach Aufwand, ein Grund).

Und das Entwickler und Designer getrennte Personen sind, ist nicht zwingend notwendig, auch wenn aus genau diesem Grund Smarty entstanden ist. Es geht hier auch denke ich nicht um die Grundsätzliche Anwendung von dem Design, vielmehr um ein sprachlich flexibel gestaltetes WebUI,was meines erachtens nach auch für einen Programmierer mit Smarty einfach umzusetzen ist.

Zu guter letzt wurde von Dir das Thema Caching angesprochen, welches Smarty ebenfalls brauchbar beherrscht.

[.vash]

ok ich kenne Smarty nicht im Detail, wenn es die Aufgaben beherrscht, kann es sich lohnen einen Blick darauf zu werden. Will ja auch keine Grundsatzdiskussion anzetteln, sondern nur darauf hinweisen, dass

1. trotzdem eine gewisse Einarbeitungszeit in ein Framework immer mit einkalkuliert werden muss.

2. ein Framework nicht unbedingt ein Allheilmittel ist

[gurkenpapst]

1. trotzdem eine gewisse Einarbeitungszeit in ein Framework immer mit einkalkuliert werden muss.

2. ein Framework nicht unbedingt ein Allheilmittel ist

niemand hat etwas anderes behauptet. Es ging um ein Problem, welches mittels Smarty lösbar ist. Dies in meiner Sicht auch noch komfortabel und in überschaubaren Umfang/Aufwand. Smarty ist aber auch nur einer von x Lösungsansätzen. Wäre dies mein x-tes Posting in dem ich Smarty als Lösung anpreisen würde, oder hätte ich geschrieben "das die anderen Lösungen alle uncool sind und nur Smarty rockt", dann hätte ich deinen Einwand eventuell verstanden.