Erweiterung für Mehrsprachigkeit

Zerobot · 13. Mär 2006, 22:02

Hallo.

$REX['CUR_CLANG'] liefert die aktuelle Sprache als Code, entsprechend der ID im Backend > Specials > Sprachen. I18N möchte aber den Namen einer Sprachdatei im Konstruktor übergeben bekommen. Möchte ich nun auf einer mehrsprachigen Seite im Frontend z.B. durch ein spezielles Modul Texte ausgeben, die nicht direkt aus Artikeln o.ä. generiert werden, muß ich selber an irgendeiner Stelle etwas bauen wie ...

Code: Alles auswählen

switch ($REX['CUR_CLANG']) {
    case 0:
        $language = 'de_DE';
        break;
    case 0:
        $language = 'en_GB';
        break;
    ...
}
$i18n = new i18n($language, ...);

Ich fänd es praktisch, wenn im oben erwähnten Backendmenü für jede Sprache auch gleich das Kürzel mit eingetragen werden und im Skript verfügbar gemacht werden könnte.

Ich könnte mir das z.B. analog zu rex_getUrl() vorstellen. Oder über das $REX-Array.

14. Mär 2006, 17:53

Hi,

ich bin mir nicht sicher, ob ich das richtig verstanden habe, aber ich glaube dir wäre mit dem opf_lang Addon aus dem CVS geholfen.

Gruß,
Markus

EDIT:
Ausserdem könnte dir auch $REX['LANG'] helfen.

Zerobot · 14. Mär 2006, 20:23

Ich schau mir das AddOn mal an. Aber $REX['LANG'] ist es nicht. Das liefert mir (so hab ich es zumindest verstanden und bisher getestet) die aktuelle Sprache im Backend. Die brauche ich aber nicht.

Zerobot · 14. Mär 2006, 22:38

Ok, ich habe gerade $REX['CLANG'] entdeckt, welches mir die momentan verfügbaren CLANGS und den Zusammenhang ID <-> Sprachname liefert. LOL, hab es die ganze Zeit übersehen.

Da ich die Sprachdateien für I18N notfalls ja auch "deutsch.lang", "english.lang" usw. nennen kann, ist ein zusätzliches Feld fürs Kürzel beim Erstellen neuer Sprachen vielleicht nicht unbedingt nötig.

Die ellenlange Erklärung für kills, die ich hier gerade geben wollte, streich ich dann mal.

Ich hab mir opf_lang mal angeschaut. Dieses AddOn könnte ich für mein Vorhaben sicher auch nutzen. Allerdings ist mir das nicht direkt genug. Ich hätte es gern "vor Ort", d.h. ich möchte die Stelle, wo Ersetzungen nötig sind, direkt angeben und nicht mit opf_lang prophylaktisch jeden Artikel meiner Seite bei jedem Aufruf mir str_replace() durchpflügen. Das bereits im Backend verwendete I18N mit den dazugehörigen ausgelagerten Sprachdateien ist mir da wesentlicher sympathischer.

15. Mär 2006, 15:52

Hi Zerobot,

Zerobot hat geschrieben:Ich hab mir opf_lang mal angeschaut. Dieses AddOn könnte ich für mein Vorhaben sicher auch nutzen. Allerdings ist mir das nicht direkt genug. Ich hätte es gern "vor Ort", d.h. ich möchte die Stelle, wo Ersetzungen nötig sind, direkt angeben und nicht mit opf_lang prophylaktisch jeden Artikel meiner Seite bei jedem Aufruf mir str_replace() durchpflügen. Das bereits im Backend verwendete I18N mit den dazugehörigen ausgelagerten Sprachdateien ist mir da wesentlicher sympathischer.

Immer drann denken, dass du dann bei einem evtl. Update von REDAXO 3.1 auf REDAXO 3.X diese Sprachdateien immer überarbeiten musst.

Wenn du eigene Sprachdateien mit einfügen willst, dann bau dir am besten auch ein Addon, indem du einfach nur ein Sprachobjekt anlegst und die Sprachdateien zur Verfügung stellst.

Gruß,
Markus

Zerobot · 15. Mär 2006, 16:59

kills hat geschrieben: Wenn du eigene Sprachdateien mit einfügen willst, dann bau dir am besten auch ein Addon, indem du einfach nur ein Sprachobjekt anlegst und die Sprachdateien zur Verfügung stellst.

Genau das hatte ich vor.

Zerobot · 16. Mär 2006, 02:41

Wird wohl doch nichts mit dem AddOn. Das Array $REX['CLANG'] mit den verfügbaren Sprachen wird offensichtlich erst initialisiert nachdem die AddOns durchgeackert wurden. Und da ich keinen passenden Extension Point dafür finden konnte, schreib ich jetzt einfach die zwei Zeilen in die master.inc.php.

Wer noch eine bessere Idee hat, kann ja mal was vorschlagen.

Übrigens mal eine Frage zu den CVS-Versionen:

Fließen in die dortige 3.1er schon Erweiterungen ein, die für 3.2 geplant sind oder ist das reines Bugfixing? Ich hab nämlich in den letzten Tagen einige Bugs gefunden, die ihr im CVS schon korrigiert habt. Brauche aber eine möglichst stabile 3.1 für Produktion.

Dr KillerJoe · 16. Mär 2006, 10:45

Die CVS-Version ist die Entwicklerversion!! Im Moment ist nur die Redaxo 3.1 stable.

Für den Produktiven Einsatz ist also die CVS-Version nicht sinnvoll, da diese immer weiterentwickelt wird!

Diesen Monat soll aber, laut Entwicklerteam, Redaxo 3.2 (stable) rauskommen.

konst · 16. Mär 2006, 18:26

Vielleicht können die Entwickler demnächst (z.B. nach V3.2) über eine Aufteilung in einen stable und einen development Zweig nachdenken. Macht natürlich mehr Arbeit - ich weiß. Wir sind ja bei der Wunschliste

16. Mär 2006, 20:07

Hi,

ich verstehe nicht ganz auf was ihr hinauswollt?

Die Stable Versionen liegen doch immer unter Downloads vor und die Entwicklerversionen ist eben im CVS...

Gruß,
Markus

svenalbert · 16. Mär 2006, 22:42

ich denke, es geht hier um die erweiterungen, die von version zu version (eben zwischendrinne) gemacht werden.

diese sind nur im CVS zu haben und wenn man pech hat, "installiert" man sich noch nen extra bug.

deswegen ein die teilung.

Zerobot · 16. Mär 2006, 23:33

konst hat geschrieben:Vielleicht können die Entwickler demnächst (z.B. nach V3.2) über eine Aufteilung in einen stable und einen development Zweig nachdenken.

Das fände ich auch sehr praktisch.

svenalbert hat geschrieben:ich denke, es geht hier um die erweiterungen, die von version zu version (eben zwischendrinne) gemacht werden.

diese sind nur im CVS zu haben und wenn man pech hat, "installiert" man sich noch nen extra bug.

Richtig, genau deswegen hab ich gefragt.

17. Mär 2006, 16:01

Hi zusammen,

meiner Meinung nach sollten wir unsere ohnehin knappe Zeit nicht auch noch damit vergeuden, alle Fehler doppelt beseitigen zu müssen.

Bisher sind wir mit unserem "aktuellen System" eigentlich gut gefahren, meiner Meinung nach.

Jan, was meinst du?

Gruß,
Markus

17. Mär 2006, 16:50

Hej,

ich verstehe ebenso wenig warum man doppelgleisig fahren sollte.

Wenn eine stable Version herauskommt , wird sie unter Downloads bereitgestellt. Das schrieb ja Markus bereits.

Die CVS-Version ist ja nicht für den produktiven Einsatz gedacht. Also sollte sie auch nicht zum Einsatz kommen. Möchte man gern Features aus der CVS Version einsetzen, dann wartet man bis zur nächsten stabilen Version.

Wer nicht warten kann, muß das mit sich vereinbaren und eben die CVS Version installieren und ggf die Fehler akzeptieren.

Ich denke, dass hier nur mehr Arbyte dahinter steckt als Nutzen herauskommt.

vg Thomas

17. Mär 2006, 17:34

hi,

wuerde natuerlich sinn machen einen zweig fuer versionsbugs.. das problem ist bisher das wir das zeitlich nicht so hin kriegen und deswegen uns erstmal noch auf einem strang bewegen werden... sobald das ganze ein wenig groesser ist werden wir das sicher aendern muessen und wollen .. ich hoffe ihr versteht das ..

lg

jan

Zerobot · 17. Mär 2006, 23:45

tbaddade hat geschrieben:Möchte man gern Features aus der CVS Version einsetzen, dann wartet man bis zur nächsten stabilen Version.

Es geht mir gar nicht um neue Features, sondern allein um die Bugfixes. (Siehe mein erstes Posting zu diesem Thema. Hab Svens Beitrag da offensichtlich nicht ganz so genau gelesen... eher am letzten Satz fest gemacht.)

I.d.R. posten die Leute hier im Forum, wenn sie einen Bug finden. Sollen sie dem Kunden wirklich eine Seite ausliefern, von der sie wissen, daß Fehler XYZ drin vorkommt? Nicht jeder weiß, wie er den Fehler selber beheben soll bzw. wie ihr ihn in der CVS-Version behoben habt. Daher der Vorschlag für einen eigenen Zweig.

Mir ist auch klar, daß das einen größeren Aufwand bedeutet. Nur ein Vorschlag, wie gesagt.