Bugs/Probleme mit Mehrsprachigkeit im akt. Snapshot
Bugs/Probleme mit Mehrsprachigkeit im akt. Snapshot
Hallo Entwickler!
Ich arbeite bereits testeshalber schon länger mit der Version 4.5. Super gut gelungen, vor allem die Mehrsprachigkeit ist ein deutlicher Fortschritt. Nun versuche ich mich daran, ein Plugin zu schreiben. Dies muss sowohl im Frontend als auch im Backend mehrere Sprachen unterstützen. Dabei sind mir im Backend folgende Probleme aufgefallen:
1. In verschiedensten Dateien wird an erster Stelle immer die Datei "startup.php" eingebunden. Dies führt jedoch in der startup.php bei der Einbindug der Plugins zu einem Fehler, da die Funktion "i18nregisterdomain" noch nicht zur Verfügung steht. Falls in allen relevanten php-Dateien immer die Datei "functions.i18n.php" vor der "startup.php" eingebunden wird, ist das Problem gelöst. Wäre gut, wenn Ihr dies schnellstmöglichst ändern könntet.
2. In den Backend-Menüs und diversen anderen Stellen erscheinen Texte immer in Deutsch. Dies liegt daran, dass die "cfg_language_de.inc.php" immer starr eingebunden wird. Hier sollte beim Include-.Befehl in allen php-Dateien, in denen diese Datei eingebunden wird, statt "de" die Anmeldesprache (z. B. de_DE oder en_EN) eingesetzt werden (z. B. "cfg_language_de_DE" oder cfg_language_en_EN"). Damit wäre gewährleistet, dass im gesamten Backend auch Mehrsprachigkeit durch die Einbindung sprach-bezogener Dateien unterstützt wird.
3. Bei der Angabe von Plugins in den Navigations-Tabellen "con_nav_main" und "con_nav-sub" muss immer im Feld "Location" die entsprechende XML-Datei des Plugins (z. B. XXXXXXXX/xml/lang_de_DE.xml;navigation/menüpunkt/main) zusätzlich angeben werden, damit in den Menüleisten des Backend die entsprechenden Menüpunkte angezeigt werden. Da der Dateiname (XXXXXXXXX/xm/lang_de_DE.xml) immer nur starr angegeben werden kann, ist hier keine Mehrsprachigkeit für die Anzeige der Menüpunkte gegeben. Es sollte hier ein Parameter (z.B. "{LOGIN-LANG}") angegeben werden können, der bei der Ausführung durch die Login-Sprache ersetzt wird. Damit wäre eine volle Unterstützung der Mehrsprachigkeit gegeben.
4. Nach meiner Auffassung sollte ein Plugin alle Elemente enthalten, die es benötigt. D. h., dass keine Änderungen in den Standarddateien von Contenido vorgenommen werden sollten, um die Releasefähigkeit zu erhalten. Leider wird aber in Contenido nirgendwo die Srpachdatei "cfg_language_de.inc.php" eingebunden. Meines Erachtens ist hier die Konfigurationsdatei des Plugins nicht geeignet, da z. B. i18n-Funktionalitäten zum Zeitpunkt des Einbindes noch nicht zur Verfügung stehen. Daher sollte in der Standard "cfg_language_xxxxxx.inc.php" analog der "startup.php" ein Einbindung der Sprachdateien aller Plugins erfolgen, sofern die Datei vorhanden ist. Dies erlaubt auch den Plugins eine volle Unterstützung der Mehrsprachigkeit. Hier der Code, wie ich ihn derzeit in die "../contenido/includes/cfg_language.inc.de" eingebaut habe:
cInclude("includes", "functions.i18n.php");
$handle = opendir($cfg['path']['contenido'] . $cfg["path"]['plugins'] );
while ($plugin = readdir($handle))
{
$langfile = $cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/includes/cfg_language_de.inc.php";
if (is_dir($cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/includes")) {
if (file_exists($langfile)) {
include_once($langfile);
}
}
}
Ich hoffe, dass ich nicht irgendwelche neue Funktionen übersehen habe und meine obigen Anmerkungen und vor allem Anpassungen dadurch hinfällig sind. Vielleicht könntet Ihr meine Anmerkungen kommentieren und ggfs. schnellstmöglich umnsetzen.
Vielen Dank und Gruss
RH
Ich arbeite bereits testeshalber schon länger mit der Version 4.5. Super gut gelungen, vor allem die Mehrsprachigkeit ist ein deutlicher Fortschritt. Nun versuche ich mich daran, ein Plugin zu schreiben. Dies muss sowohl im Frontend als auch im Backend mehrere Sprachen unterstützen. Dabei sind mir im Backend folgende Probleme aufgefallen:
1. In verschiedensten Dateien wird an erster Stelle immer die Datei "startup.php" eingebunden. Dies führt jedoch in der startup.php bei der Einbindug der Plugins zu einem Fehler, da die Funktion "i18nregisterdomain" noch nicht zur Verfügung steht. Falls in allen relevanten php-Dateien immer die Datei "functions.i18n.php" vor der "startup.php" eingebunden wird, ist das Problem gelöst. Wäre gut, wenn Ihr dies schnellstmöglichst ändern könntet.
2. In den Backend-Menüs und diversen anderen Stellen erscheinen Texte immer in Deutsch. Dies liegt daran, dass die "cfg_language_de.inc.php" immer starr eingebunden wird. Hier sollte beim Include-.Befehl in allen php-Dateien, in denen diese Datei eingebunden wird, statt "de" die Anmeldesprache (z. B. de_DE oder en_EN) eingesetzt werden (z. B. "cfg_language_de_DE" oder cfg_language_en_EN"). Damit wäre gewährleistet, dass im gesamten Backend auch Mehrsprachigkeit durch die Einbindung sprach-bezogener Dateien unterstützt wird.
3. Bei der Angabe von Plugins in den Navigations-Tabellen "con_nav_main" und "con_nav-sub" muss immer im Feld "Location" die entsprechende XML-Datei des Plugins (z. B. XXXXXXXX/xml/lang_de_DE.xml;navigation/menüpunkt/main) zusätzlich angeben werden, damit in den Menüleisten des Backend die entsprechenden Menüpunkte angezeigt werden. Da der Dateiname (XXXXXXXXX/xm/lang_de_DE.xml) immer nur starr angegeben werden kann, ist hier keine Mehrsprachigkeit für die Anzeige der Menüpunkte gegeben. Es sollte hier ein Parameter (z.B. "{LOGIN-LANG}") angegeben werden können, der bei der Ausführung durch die Login-Sprache ersetzt wird. Damit wäre eine volle Unterstützung der Mehrsprachigkeit gegeben.
4. Nach meiner Auffassung sollte ein Plugin alle Elemente enthalten, die es benötigt. D. h., dass keine Änderungen in den Standarddateien von Contenido vorgenommen werden sollten, um die Releasefähigkeit zu erhalten. Leider wird aber in Contenido nirgendwo die Srpachdatei "cfg_language_de.inc.php" eingebunden. Meines Erachtens ist hier die Konfigurationsdatei des Plugins nicht geeignet, da z. B. i18n-Funktionalitäten zum Zeitpunkt des Einbindes noch nicht zur Verfügung stehen. Daher sollte in der Standard "cfg_language_xxxxxx.inc.php" analog der "startup.php" ein Einbindung der Sprachdateien aller Plugins erfolgen, sofern die Datei vorhanden ist. Dies erlaubt auch den Plugins eine volle Unterstützung der Mehrsprachigkeit. Hier der Code, wie ich ihn derzeit in die "../contenido/includes/cfg_language.inc.de" eingebaut habe:
cInclude("includes", "functions.i18n.php");
$handle = opendir($cfg['path']['contenido'] . $cfg["path"]['plugins'] );
while ($plugin = readdir($handle))
{
$langfile = $cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/includes/cfg_language_de.inc.php";
if (is_dir($cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/includes")) {
if (file_exists($langfile)) {
include_once($langfile);
}
}
}
Ich hoffe, dass ich nicht irgendwelche neue Funktionen übersehen habe und meine obigen Anmerkungen und vor allem Anpassungen dadurch hinfällig sind. Vielleicht könntet Ihr meine Anmerkungen kommentieren und ggfs. schnellstmöglich umnsetzen.
Vielen Dank und Gruss
RH
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Ich glaube das ist fast alles hinfällig. Um ein Plugin übersetzbar zu machen:
i18nregisterdomain mußt du nicht selbst machen: Das wird (zumindest in den aktuellen Snapshots) automatisch gemacht (siehe Ende der Datei cfg_language_de.inc.php). Wichtig ist, daß dort im Verzeichnis plugins/<pluginname>/includes eine Datei namens config.plugin.php liegt und in plugins/<pluginname>/ ein Verzeichnis namens "locale".
Die Locales legst du dann in obiges Verzeichnis locale. Damit hat sich Punkt 1 erledigt
Zu 2.: Zwar heißt die cfg_language_de.inc.php so, aber diese Datei selbst ist schon übersetzbar (zumindest die Punkte, die auch wirklich noch verwendet werden, der Rest ist 4.2-Kompatibilitätskram). Durch die i18n-Funktion werden diese ja dann zur Laufzeit übersetzt.
Zu 3.: Das ist noch ein offener Punkt
Zu 4.: Genauso sehen wir das auch, und deshalb braucht man auch an den Standardfiles von Contenido nichts ändern
Siehe oben. Eventuell hast du noch eine alte Version? In den Snapshots ist das schon gelöst.
i18nregisterdomain mußt du nicht selbst machen: Das wird (zumindest in den aktuellen Snapshots) automatisch gemacht (siehe Ende der Datei cfg_language_de.inc.php). Wichtig ist, daß dort im Verzeichnis plugins/<pluginname>/includes eine Datei namens config.plugin.php liegt und in plugins/<pluginname>/ ein Verzeichnis namens "locale".
Die Locales legst du dann in obiges Verzeichnis locale. Damit hat sich Punkt 1 erledigt

Zu 2.: Zwar heißt die cfg_language_de.inc.php so, aber diese Datei selbst ist schon übersetzbar (zumindest die Punkte, die auch wirklich noch verwendet werden, der Rest ist 4.2-Kompatibilitätskram). Durch die i18n-Funktion werden diese ja dann zur Laufzeit übersetzt.
Zu 3.: Das ist noch ein offener Punkt
Zu 4.: Genauso sehen wir das auch, und deshalb braucht man auch an den Standardfiles von Contenido nichts ändern

ein grossteil der punkte kommt ebenso hier vor:
-> http://www.contenido.org/forum/viewtopi ... highlight=
punkt 3 ist dort auch kein thema mehr
-> http://www.contenido.org/forum/viewtopi ... highlight=
punkt 3 ist dort auch kein thema mehr

*** make your own tools (wishlist :: thx)
Also erstmal: ich bin platt. Gerade eingestellt und schon eine Antwort. Das ist der schnellste Support, den ich je in einem Forum erhalten habe. Kompliment!!! 
So, und nun zu Deinen Anmerkungen:
1. Ich setze die Version vom 31.12.2004 ein.
2. Die i18n wird zwar am Ende der cfg_language.inc.de eingebunden (habe ich gesehen), ist aber viel zu spät. Als erstes wird immer die Datei startup.php eingebunden. In dieser ist die Einbindung der Plugins mit der Funktion i18nregisterdomain. Diese Funktion läuft in allen Backend-Frames auf den Fehler, dass die Funktion nicht vorhanden ist. Ist auch klar, kann noch nicht vorhanden sein, da die Einbindung der cfg_language_de.inc.php erst viel später erfolgt (siehe "frameset.php" oder frameset_left.php"). Der Fehler tritt also immer nur bei den ersten zu ladenden Dateien (vorwiegend in ../contenido/frame...) auf.
3. Ich habe eine Plugin-Sprachdatei im Verzeichnis locale sehr wohl angelegt und auch ordnungsgemäss gefüllt.
4. Die Sprachdatei des Plugins nutzt gar nix, wenn ich nicht die entsprechenden Aktionen aus der Tabelle actions für das Plugins (z. B. für die Rechtevergabe) übersetzen kann. Einerseits erfolgt ja die Übersetzung automatisch beim Anzeigen der Backend-Menüleisten. Soweit so gut, bis auf die fehlende Unterstützung der Mehrsprachigkeit. Aber soweit ich erkennen konnte, wird z. B. in den Masken zur Vergabe der Rechte (Admin-Benutzer-Benutzer auswählen-Bereiche) unbedingt für die Contenido-Aktionen die Datei cfg_language_de.inc.php benötigt, damit die Texte für die Einträge aus der Tabelle "actions" ordnungsgemäss mit Texten angezeigt und übersetzt werden. Daher muss ich für mein Plugin unbedingt Einträge in der Form
$lngAct["plugin-areaname"]["plugin-action"] = i18n("plug-action", "plugin-name");
(Beispiel: $lngAct["address"]["address_delete"] = i18n("Delete Address", "products");
irgendwo analog dem Contenido-Standard hinterlegen, die dann in Contenido eingebunden werden, damit ich auch für mein Plugin Texte in den Rechten angezeigt bekomme. Ansonsten bleibt nämlich der Text leer und ich kann in den Rechten nicht erkennen, welches Flag ich setze. Bis dato konnte ich nicht erkennen, wie ich das anders als in einer eigenen cfg_language_de.ic.de, die ich in meinem include-Verzeichnis des Plugins hinterlege und in die Standard-Datei cfg_language_de.inc.php im Contenido-include Verzeichnis einbinde, lösen kann. Falls es einen anderen Weg gibt, teil mir dies doch bitte mit. Danke.
Kleiner Verbesserungsvorschlag am Rande: falls die Datei cfg_language_de.inc.php auch weiterhin benötigt wird und durch i18n sowieso problemlos übersetzbar ist, werft doch bitte das "_de" aus dem Dateinamen raus. Das irritiert nur.

So, und nun zu Deinen Anmerkungen:
1. Ich setze die Version vom 31.12.2004 ein.
2. Die i18n wird zwar am Ende der cfg_language.inc.de eingebunden (habe ich gesehen), ist aber viel zu spät. Als erstes wird immer die Datei startup.php eingebunden. In dieser ist die Einbindung der Plugins mit der Funktion i18nregisterdomain. Diese Funktion läuft in allen Backend-Frames auf den Fehler, dass die Funktion nicht vorhanden ist. Ist auch klar, kann noch nicht vorhanden sein, da die Einbindung der cfg_language_de.inc.php erst viel später erfolgt (siehe "frameset.php" oder frameset_left.php"). Der Fehler tritt also immer nur bei den ersten zu ladenden Dateien (vorwiegend in ../contenido/frame...) auf.
3. Ich habe eine Plugin-Sprachdatei im Verzeichnis locale sehr wohl angelegt und auch ordnungsgemäss gefüllt.
4. Die Sprachdatei des Plugins nutzt gar nix, wenn ich nicht die entsprechenden Aktionen aus der Tabelle actions für das Plugins (z. B. für die Rechtevergabe) übersetzen kann. Einerseits erfolgt ja die Übersetzung automatisch beim Anzeigen der Backend-Menüleisten. Soweit so gut, bis auf die fehlende Unterstützung der Mehrsprachigkeit. Aber soweit ich erkennen konnte, wird z. B. in den Masken zur Vergabe der Rechte (Admin-Benutzer-Benutzer auswählen-Bereiche) unbedingt für die Contenido-Aktionen die Datei cfg_language_de.inc.php benötigt, damit die Texte für die Einträge aus der Tabelle "actions" ordnungsgemäss mit Texten angezeigt und übersetzt werden. Daher muss ich für mein Plugin unbedingt Einträge in der Form
$lngAct["plugin-areaname"]["plugin-action"] = i18n("plug-action", "plugin-name");
(Beispiel: $lngAct["address"]["address_delete"] = i18n("Delete Address", "products");
irgendwo analog dem Contenido-Standard hinterlegen, die dann in Contenido eingebunden werden, damit ich auch für mein Plugin Texte in den Rechten angezeigt bekomme. Ansonsten bleibt nämlich der Text leer und ich kann in den Rechten nicht erkennen, welches Flag ich setze. Bis dato konnte ich nicht erkennen, wie ich das anders als in einer eigenen cfg_language_de.ic.de, die ich in meinem include-Verzeichnis des Plugins hinterlege und in die Standard-Datei cfg_language_de.inc.php im Contenido-include Verzeichnis einbinde, lösen kann. Falls es einen anderen Weg gibt, teil mir dies doch bitte mit. Danke.
Kleiner Verbesserungsvorschlag am Rande: falls die Datei cfg_language_de.inc.php auch weiterhin benötigt wird und durch i18n sowieso problemlos übersetzbar ist, werft doch bitte das "_de" aus dem Dateinamen raus. Das irritiert nur.
Hi emergence!
Danke auch für Deine Antwort. Den Task habe ich sehr wohl vorher gelsen (ich versuche zumindest ein "ordentlicher" Forumteilnehmer zu sein und suche vorher nach den Themen).
Gleichwohl ist das Hello-World Plugin so einfach, dass nur Übersetzung innerhalb des Moduls durchgeführt wird. Mein Plugin ist jedoch sehr komplex (habe z. B. mehr als 100 Aktionen in die Tabelle actions eingefügt und arbeite mit mindestens 20 neuen Datenbanktabellen und 50 php-Dateien) und nutze alle Standardfunktionen Contenido aus.
Aus diesem Grund habe ich den Beitrag gepostet, da ich noch einige kleine Verbesserungsmöglichkeiten bei der Fremdsprachigkeit sehe und eigentlich selbst keinerlei Änderungen am Core-System vornehmen möchte. Hab ich zwar getan, muss ich aber beim Einspielen jeder neuen Contenido-Version nachziehen. Deshalb würde ich es besser finden, wenn ich am Contenido-Core überhaupt keine Änderungen vornehmen muss, um mit meinem Plugin alle Funktionen von Contenido zu nutzen.
Danke auch für Deine Antwort. Den Task habe ich sehr wohl vorher gelsen (ich versuche zumindest ein "ordentlicher" Forumteilnehmer zu sein und suche vorher nach den Themen).
Gleichwohl ist das Hello-World Plugin so einfach, dass nur Übersetzung innerhalb des Moduls durchgeführt wird. Mein Plugin ist jedoch sehr komplex (habe z. B. mehr als 100 Aktionen in die Tabelle actions eingefügt und arbeite mit mindestens 20 neuen Datenbanktabellen und 50 php-Dateien) und nutze alle Standardfunktionen Contenido aus.
Aus diesem Grund habe ich den Beitrag gepostet, da ich noch einige kleine Verbesserungsmöglichkeiten bei der Fremdsprachigkeit sehe und eigentlich selbst keinerlei Änderungen am Core-System vornehmen möchte. Hab ich zwar getan, muss ich aber beim Einspielen jeder neuen Contenido-Version nachziehen. Deshalb würde ich es besser finden, wenn ich am Contenido-Core überhaupt keine Änderungen vornehmen muss, um mit meinem Plugin alle Funktionen von Contenido zu nutzen.
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Hmm, das habe ich bisher noch nicht festgestellt - denn wir haben die Übersetzungen bei vielen Projekten im Einsatz...ich überlege nur gerade, wo es bei dir hängen könnte...RH hat geschrieben:2. Die i18n wird zwar am Ende der cfg_language.inc.de eingebunden (habe ich gesehen), ist aber viel zu spät. Als erstes wird immer die Datei startup.php eingebunden. In dieser ist die Einbindung der Plugins mit der Funktion i18nregisterdomain. Diese Funktion läuft in allen Backend-Frames auf den Fehler, dass die Funktion nicht vorhanden ist. Ist auch klar, kann noch nicht vorhanden sein, da die Einbindung der cfg_language_de.inc.php erst viel später erfolgt (siehe "frameset.php" oder frameset_left.php"). Der Fehler tritt also immer nur bei den ersten zu ladenden Dateien (vorwiegend in ../contenido/frame...) auf.
Ähm das habe ich nicht ganz verstanden...4. Die Sprachdatei des Plugins nutzt gar nix, wenn ich nicht die entsprechenden Aktionen aus der Tabelle actions für das Plugins (z. B. für die Rechtevergabe) übersetzen kann.
Also ich definiere diese Variablen immer in der config.plugin.php, da diese sowieso überall eingebunden wird. Wichtig ist ein global $lngAct am Anfang.Aber soweit ich erkennen konnte, wird z. B. in den Masken zur Vergabe der Rechte (Admin-Benutzer-Benutzer auswählen-Bereiche) unbedingt für die Contenido-Aktionen die Datei cfg_language_de.inc.php benötigt, damit die Texte für die Einträge aus der Tabelle "actions" ordnungsgemäss mit Texten angezeigt und übersetzt werden. Daher muss ich für mein Plugin unbedingt Einträge in der Form
$lngAct["plugin-areaname"]["plugin-action"] = i18n("plug-action", "plugin-name");
(Beispiel: $lngAct["address"]["address_delete"] = i18n("Delete Address", "products");
irgendwo analog dem Contenido-Standard hinterlegen, die dann in Contenido eingebunden werden, damit ich auch für mein Plugin Texte in den Rechten angezeigt bekomme. Ansonsten bleibt nämlich der Text leer und ich kann in den Rechten nicht erkennen, welches Flag ich setze. Bis dato konnte ich nicht erkennen, wie ich das anders als in einer eigenen cfg_language_de.ic.de, die ich in meinem include-Verzeichnis des Plugins hinterlege und in die Standard-Datei cfg_language_de.inc.php im Contenido-include Verzeichnis einbinde, lösen kann.
Wenn Du die $lngAct[.....] immer mit in die config.plugin.php einbaust, ist das Thema natürlich grundsätzlich gelöst. Vergiss daher meine Anmerkungen zu den Übersetzungen für die Aktionen. Ich wollte mich natürlich bei meinem Plugin voll und ganz an die Contenido-Standards halten und habe daher mir auch eine eigene cfg_language_de.inc.php gebaut. Wenn ich, wie Du das immer löst, diese Angaben in die config-Datei einbaue ist das natürlich problemlos(er) und löst das Problem grundsätzlich auch (vielleicht solltet Ihr mal eine ausführlichere Anleitung für das Schreiben von Plugins erstellen).
Allerdings schlägt bei mir dann wieder das i18n-Problem zu:
Die Plugin-cfg wird in der startup.php eingebunden. Zu diesem Zeitpunkt ist die function.18n.php-Datei noch nicht eingebunden (siehe meine anderen Anmerkungen). Daher schlägt die Übersetzung in der config.plugin.php bei mir fehl und die Texte sind leer.
Allerdings schlägt bei mir dann wieder das i18n-Problem zu:
Die Plugin-cfg wird in der startup.php eingebunden. Zu diesem Zeitpunkt ist die function.18n.php-Datei noch nicht eingebunden (siehe meine anderen Anmerkungen). Daher schlägt die Übersetzung in der config.plugin.php bei mir fehl und die Texte sind leer.
ähm das ist so nicht ganz korrekt, ich sehe mir gerade die startup.php der contenido-cvs-45-2004-12-31.tar an...RH hat geschrieben:Allerdings schlägt bei mir dann wieder das i18n-Problem zu:
Die Plugin-cfg wird in der startup.php eingebunden. Zu diesem Zeitpunkt ist die function.18n.php-Datei noch nicht eingebunden (siehe meine anderen Anmerkungen). Daher schlägt die Übersetzung in der config.plugin.php bei mir fehl und die Texte sind leer.
da wird die config.plugin.php auf keinen fall mit eingebunden
dies wird erst in der cfg_language_de.inc.php gemacht (das _de sollte wirklich entfernt werden)
wieso das etwas mit frameset.php zu tun haben sollte ist mir eigentlich auch nicht ganz klar, nun gut wie auch immer
sämtliche seiten die via actions und areas nachgeladen werden bedienen sich der main.php
und dort finde ich das hier:
Code: Alles auswählen
i18nInit($cfg["path"]["contenido"].$cfg["path"]["locale"], $belang);
cInclude ("includes", 'cfg_language_de.inc.php');
*** make your own tools (wishlist :: thx)
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
das mit den Plugins ist so eine Sache (hatte ich an anderer Stelle schonmal erwähnt): Da es keine Definition gibt, was ein Plugin ist, und wie es gehandhabt wird, wird es noch keine Anleitung geben. Da wir im Moment konzeptionell an neuen Themen dran sind, wird es das so schnell leider auch nicht geben. Würden wir es im derzeitigen Zustand dokumentieren, dann würden sich viele Leute melden und Dinge bemängeln, die derzeit schlicht und ergreifend nicht funktionieren.
Aber zurück zum Thema:
Da hast du verdammt Recht
Vor einigen Wochen gab es mal einen Umzug der Methode, allerdings hat wohl das niemand getestet...
Füge mal folgende Zeile in der Startup.php direkt nach dem cInclude für die prepend.php3 ein:
cInclude("includes", "functions.i18n.php");
Wenn das bei dir funktioniert, kann ich dir fix einen neuen Snapshot erzeugen.
Aber zurück zum Thema:
Da hast du verdammt Recht

Füge mal folgende Zeile in der Startup.php direkt nach dem cInclude für die prepend.php3 ein:
cInclude("includes", "functions.i18n.php");
Wenn das bei dir funktioniert, kann ich dir fix einen neuen Snapshot erzeugen.
ach wie schön im cvs_head ist das ja wirklich gewandert...
das kommt davon das ich die snapshots nicht mehr testen kann...
das kommt davon das ich die snapshots nicht mehr testen kann...

*** make your own tools (wishlist :: thx)
ich wär dir wirklich dankbar wenn das hier gefixt werden würde
-> http://www.contenido.org/forum/viewtopi ... t=iterator
-> http://www.contenido.org/forum/viewtopi ... t=iterator
*** make your own tools (wishlist :: thx)
Also das funzt tadellos! Das i18nregisterdomain Problem ist damit gelöst.
Aber nun in diesem Zusammenhang doch noch mal zurück zum Thema Übersetzungen:
Wenn ich meine Übersetzung der Aktionen aus der Tabelle actions ($lngact[...]) in die config.plugin.php verlege oder meine cfg_language_de.inc.php inkludiere, funktioniert die Übersetzung nicht. Ursache ist, dass die init-Funktion für i18n in den frameset-Dateien erst viel später erfolgt.
Das Ganze läuft also derzeit noch nicht sauber. Ich würde vorschlagen - auch aus Kompatibilitätsgründen - dass in jedes Plugin-Include-Verzeichnis eine cfg_language.inc.php mit erstellt werden muss, falls Übersetzungen des Plugins innerhalb des Contenido-Core-System erforderlich sind (siehe Thematik Menüpunkte im Backend).
Ich habe das Ganze folgendermassen gelöst:
1. Anlegen einer cfg_language.inc.php im Include-Verzeichnis des Plugins mit den Übersetzungen
2. An das Ende der cfg_language_de.inc.php im Include-Verzeichnis Contenido habe ich folgenden Code eingebunden, der die Sprachdateien aller Plugins einliest:
/* Include plugin language translations */
$handle = opendir($cfg['path']['contenido'] . $cfg["path"]['plugins'] );
while ($plugin = readdir($handle)) {
$langfile = $cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/includes/cfg_language.inc.php";
if (is_dir($cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin )) {
if (file_exists($langfile)) {
include_once($langfile);
}
}
}
/* End of inclusion of plugin language translations */
Das Ganze wurde von mir so erfolgreich getestet und läuft wie am Schnürchen.
Gruss
RH
Aber nun in diesem Zusammenhang doch noch mal zurück zum Thema Übersetzungen:
Wenn ich meine Übersetzung der Aktionen aus der Tabelle actions ($lngact[...]) in die config.plugin.php verlege oder meine cfg_language_de.inc.php inkludiere, funktioniert die Übersetzung nicht. Ursache ist, dass die init-Funktion für i18n in den frameset-Dateien erst viel später erfolgt.
Das Ganze läuft also derzeit noch nicht sauber. Ich würde vorschlagen - auch aus Kompatibilitätsgründen - dass in jedes Plugin-Include-Verzeichnis eine cfg_language.inc.php mit erstellt werden muss, falls Übersetzungen des Plugins innerhalb des Contenido-Core-System erforderlich sind (siehe Thematik Menüpunkte im Backend).
Ich habe das Ganze folgendermassen gelöst:
1. Anlegen einer cfg_language.inc.php im Include-Verzeichnis des Plugins mit den Übersetzungen
2. An das Ende der cfg_language_de.inc.php im Include-Verzeichnis Contenido habe ich folgenden Code eingebunden, der die Sprachdateien aller Plugins einliest:
/* Include plugin language translations */
$handle = opendir($cfg['path']['contenido'] . $cfg["path"]['plugins'] );
while ($plugin = readdir($handle)) {
$langfile = $cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin . "/includes/cfg_language.inc.php";
if (is_dir($cfg['path']['contenido'] . $cfg["path"]['plugins'] . $plugin )) {
if (file_exists($langfile)) {
include_once($langfile);
}
}
}
/* End of inclusion of plugin language translations */
Das Ganze wurde von mir so erfolgreich getestet und läuft wie am Schnürchen.
Gruss
RH