die Umschaltung zwischen den Sprachen auf meiner Homepage sieht soweit ganz gut aus.
Aber nur so lange man nicht hinter die Kulissen schaut.
Ein Problem hierbei ist das die Sprache die gesetzt werden soll in der base_vars.js festgelegt wird.
Ebenso stehen in der base-vars.js alle Staus und Fehlercodes.
Dies habe ich bis jetzt so gelöst, das ich zwi verschiedene base_vars.js habe, eine für Deutsch und eine für Englisch.
Die Deutsche base_bast liegt im Unterverzeichnis "Daten" und wird täglich vom Solarlog neu generiert.
Die Englische Version ist eine Kopie der aktuellen Datei mit den notwendigen Übersetzungen und dem Sprachkenzeichen "EN".
Sie befindet sich im Unterverzeichnis "english".
Je nach der gewählten Sprache öfne ich nun die Homepage im Stammverzeichnis oder im Unterverzeichnis "english"
Alle Datenquellen hohle ich mir nun über die neue Datei "extra_vars.js"
hier ist die Variable für den "pfad" hinterlegt und eine zweite Variable "pfad_base-vars".
Je nach dem in welchem Verzeichnis die Homepage aufgerufen wird, ist in der "extra_vars.js" für "pfad_base_vars" Das Verzeichnis (http://www.meinephotovoltaik-anlage.de/Daten) oder (http://www-meinephotovoltaik-anlage.de/english) festgelegt.
Funktioniert, ist aber unprofessionell.
Hat jemand eine Idee, wie man änlich wie bei den Flags für einzelne Wechselrichter abhängig von der gewählten Sprache nur noch die Variable "pfad_base_vars" für die richtige Sprache zuweisen kann.
So müsste in dem Unterverzeichnis "english" nur noch die geänderte "base_vars.js" liegen.
Zur Zeit reichen meine Programmierkentnisse hierfür nicht aus.
Vielleicht hat jemand einen Vorschlag der sich recht einfach umsetzen lässt.
Info: Betreiber
Angemeldet: 05.05.2007
Beiträge: 1093
Wohnort: Region Hannover
Verfasst am:
22.10.2007, 21:36
Also ich verstehe das Problem mit der base_vars.js nicht so richtig.
Bei der Einrichtung des SL wird die Sprache in der Variablen Lang festgelegt. Die anderen Parameter sind Sprachneutral oder bezeichnen Status- oder Fehlermeldungen wie sie von WR gesendet werden. Ein Verändern dieser Meldungen halte ich für wenig Vorteilhaft, ist doch die Information dann nicht mehr mit der Dokumentation abgleichbar. Begriffe wie "Warten", "Fehler" oder "Stoer" sind auch einem Nichtdeutschen zumutbar, ich muss ja auch Begriffe wie "Offline", "Offset" oder "Derating" verkraften.
Durch das Erstellen einer weiteren base_vars.js wird ein zusätzlicher Pflegeaufwand generiert. Veränderungen von Parametern im SL werden dazu führen, dass die Darstellungen in den verschiedenen Sprachen abweichen. Machen wir uns nichts vor, wenn jemand nächstes Jahr seine prozentuale Aufteilung der Erträge z.B. verändert wird an die manuell anzupassende Datei nicht mehr gedacht.
Bleibt also nur die Variable Lang die es gilt zu umgehen.
Die Sprachauswahl wird wohl im Script links.html vorgenommen. Hier kann eine Hilfsvariable benutzt werden. Beim anschließenden Aufrufen eines Verarbeitungsscriptes (visu.html) wird diese Hilfsvariable genauso wie der Modus oder die Flags übergeben. Im neuen Script wird in der Regel am Anfang die Datei base_vars.js eingelesen. Danach müsste dann die Variable Lang mit Hilfe der Hilfsvariablen manipuliert werden. Danach kann dann die entsprechende lang_XX.js-Datei mit den übersetzten Texten eingelesen werden.
Wenn wirklich die Status- oder Fehlermeldungen verändert werden sollen, so kann dieses - und nur dieses - über die Datei lang_XX.js mit erledigt werden, aber ich halte diesen Schritt für Kontraproduktiv.
<polemik>
Wir raten hier zu deutschen Modulen und deutschen WR und trauen uns nicht deutsche Status- oder Fehlermeldungen zu präsentieren?
</polemik>
Sonnige Grüße
Harald
_________________ Alles meine persönliche Meinung. Ohne Gewähr für Vollständigkeit oder Richtigkeit.
Also ich verstehe das Problem mit der base_vars.js nicht so richtig.
Bei der Einrichtung des SL wird die Sprache in der Variablen Lang festgelegt. Die anderen Parameter sind Sprachneutral oder bezeichnen Status- oder Fehlermeldungen wie sie von WR gesendet werden. Ein Verändern dieser Meldungen halte ich für wenig Vorteilhaft, ist doch die Information dann nicht mehr mit der Dokumentation abgleichbar. Begriffe wie "Warten", "Fehler" oder "Stoer" sind auch einem Nichtdeutschen zumutbar, ich muss ja auch Begriffe wie "Offline", "Offset" oder "Derating" verkraften.
Durch das Erstellen einer weiteren base_vars.js wird ein zusätzlicher Pflegeaufwand generiert. Veränderungen von Parametern im SL werden dazu führen, dass die Darstellungen in den verschiedenen Sprachen abweichen. Machen wir uns nichts vor, wenn jemand nächstes Jahr seine prozentuale Aufteilung der Erträge z.B. verändert wird an die manuell anzupassende Datei nicht mehr gedacht.
Bleibt also nur die Variable Lang die es gilt zu umgehen.
Die Sprachauswahl wird wohl im Script links.html vorgenommen. Hier kann eine Hilfsvariable benutzt werden. Beim anschließenden Aufrufen eines Verarbeitungsscriptes (visu.html) wird diese Hilfsvariable genauso wie der Modus oder die Flags übergeben. Im neuen Script wird in der Regel am Anfang die Datei base_vars.js eingelesen. Danach müsste dann die Variable Lang mit Hilfe der Hilfsvariablen manipuliert werden. Danach kann dann die entsprechende lang_XX.js-Datei mit den übersetzten Texten eingelesen werden.
Wenn wirklich die Status- oder Fehlermeldungen verändert werden sollen, so kann dieses - und nur dieses - über die Datei lang_XX.js mit erledigt werden, aber ich halte diesen Schritt für Kontraproduktiv.
<polemik>
Wir raten hier zu deutschen Modulen und deutschen WR und trauen uns nicht deutsche Status- oder Fehlermeldungen zu präsentieren?
</polemik>
Sonnige Grüße
Harald
Hallo Harald,
mit dem was Du sagst hast Du vollkommen Recht.
Aber wenn es so fuktioniert, dann ist es auch egal ob sich die Auswahl auf die Variable +lang+ oder auf die Variable +pfad_base_vars+ auswirkt.
Derzeit ist es so das +lang+ zentral aus der base_vars.js gezogen wird, und diese wird zur Zeit mehrfach am Tag vom Solarlog neu erzeugt.
Ich denke auch das wir hier in Deutschland zu unserer deutschen Sprache stehen sollten.
Aber wenn ein Wechselrichter mit dem Solarlog außerhalb Deutschlands in einer anderen Landesprache eingesetzt wird, dann sind die Status und Fehlercodes auch in der anderen Sprache.
Für mich ist es hilfreich wenn ich mit einem nicht deutschprachigen Kollegen über Statuscodes und Fehlercodes spreche, das ich sie nur einmal übersetzten muss. Egal ob der Wechselrichter in meinem Land installiert ist oder in seinem. Vor allem dann wenn englisch nur der Mittelweg ist.
Meine Anforderungen sind da etwas höher, daher würde ich es auf die +pfad_base_vars+ beziehen und die zweite Datei pflegen.
Wer das nicht für nötig hält nimmt halt die +lang+
Da sollte das umgesetzt sein. Du musst nur dafür sorgen, das die Links entsprechend ein &lang=EN oder ?lang=EN enthalten für Englisch, oder ein &lang=DE oder ?lang=DE enthalten für Deustch. Sollte kein Parameter übergeben werden, wird automatisch das aus dem base_vars.js übernommen.
Hoffe das deckt das ab was Du willst.....
Stefan
_________________ 12.1 kWp bestehend aus:
49 Sunways SM215 an einem Sunways NT10000 (seit 05.06.2007)
und
7 SolarFabrik 150/10 an einem SMA SunnyBoy 1100 (seit 22.03.2008) und Solarlog 800e.
http://www.stefan-bauer.net/daten/SolarLog/
Da sollte das umgesetzt sein. Du musst nur dafür sorgen, das die Links entsprechend ein &lang=EN oder ?lang=EN enthalten für Englisch, oder ein &lang=DE oder ?lang=DE enthalten für Deustch. Sollte kein Parameter übergeben werden, wird automatisch das aus dem base_vars.js übernommen.
Hoffe das deckt das ab was Du willst.....
Stefan
Hallo Stefan,
Da muss ich ja jeden Link doppelt verwalten. Das Ziel sollte schon sein Zentral zu entscheiden welche base_var.js verwendet wird.
Änlich wie Du es in Deinem Ereignisprotokol gemacht hast, mit direkter Umschaltung
Entweder Einzelne Wechselrichter oder alle.
Je nach der zwischengespeicherten Sprache, wird hier die Entscheidung getroffen, welche base Vars genommen wird.
Da sollte das umgesetzt sein. Du musst nur dafür sorgen, das die Links entsprechend ein &lang=EN oder ?lang=EN enthalten für Englisch, oder ein &lang=DE oder ?lang=DE enthalten für Deustch. Sollte kein Parameter übergeben werden, wird automatisch das aus dem base_vars.js übernommen.
Hoffe das deckt das ab was Du willst.....
jep, so hatte ich es gedacht. Aber der Parameter müsste doch immer übergeben werden?
Wenn bei einer deutschen Anlage englisch als Sprache ausgewählt wird, wird das EN mit übergeben und entsprechend ausgewertet. Wird nun in der Anzeige der Werte z.B. vom Tag auf den Monat gewechselt wird die visu.html ja mit neuen Parametern (modus) aufgerufen. Wenn dabei &lang oder ?lang nicht mit übergeben wird ist doch die Sprachauswahl weg?
Sonnige Grüße
Harald
_________________ Alles meine persönliche Meinung. Ohne Gewähr für Vollständigkeit oder Richtigkeit.
Da sollte das umgesetzt sein. Du musst nur dafür sorgen, das die Links entsprechend ein &lang=EN oder ?lang=EN enthalten für Englisch, oder ein &lang=DE oder ?lang=DE enthalten für Deustch. Sollte kein Parameter übergeben werden, wird automatisch das aus dem base_vars.js übernommen.
Hoffe das deckt das ab was Du willst.....
Stefan
Hallo Stefan,
Da muss ich ja jeden Link doppelt verwalten. Das Ziel sollte schon sein Zentral zu entscheiden welche base_var.js verwendet wird.
Die Sprache wird doch als (Hilfs-)Variable mitgeführt, somit bleibt es bei einem Link.
Ich stehe weiterhin auf dem Standpunkt das es nur eine base_vars.js geben kann und darf. Es können doch nur einige wenige Variablen aus der base_vars.js sein, die einer Übersetzung bedürfen. Diese Variablen - und nur diese - können zusätzlich in der abweichenden lang_XX.js neu definiert werden und überschreiben dann die ursprünglichen Inhalte.
Die lang_XX.js wird doch immer nach der base_vars.js in Abhängigkeit der Variablen Lang aus der base_vars.js gelesen
Sonnige Grüße
Harald
_________________ Alles meine persönliche Meinung. Ohne Gewähr für Vollständigkeit oder Richtigkeit.
Ich stehe weiterhin auf dem Standpunkt das es nur eine base_vars.js geben kann und darf. Es können doch nur einige wenige Variablen aus der base_vars.js sein, die einer Übersetzung bedürfen. Diese Variablen - und nur diese - können zusätzlich in der abweichenden lang_XX.js neu definiert werden und überschreiben dann die ursprünglichen Inhalte.
Die lang_XX.js wird doch immer nach der base_vars.js in Abhängigkeit der Variablen Lang aus der base_vars.js gelesen
Sonnige Grüße
Harald
Hallo Harald,
diese Variablen habe ich in den langXX.js Dateien ja schon definiert und auch übersetzt.
Das Problem hierbei ist, das die Variable [+lang+] ebenfalls in der base_vars.js steht und diese wird mehrmals am Tag neu geschrieben.
Also ist die Sprache immer Deutsch für die gesamte Homepage.
Wenn ich also English will muss ich die Variable aus einer Datei hohlen die nicht ständig mit DE neu geschrieben wird.
Die Variable müsste Außerhalb der base_vars.js stehen, das ist aber nicht der Fall.
Info: Betreiber
Angemeldet: 05.05.2007
Beiträge: 1093
Wohnort: Region Hannover
Verfasst am:
23.10.2007, 01:37
Captain auroPOWER hat Folgendes geschrieben:
das399igste hat Folgendes geschrieben:
Ich stehe weiterhin auf dem Standpunkt das es nur eine base_vars.js geben kann und darf. Es können doch nur einige wenige Variablen aus der base_vars.js sein, die einer Übersetzung bedürfen. Diese Variablen - und nur diese - können zusätzlich in der abweichenden lang_XX.js neu definiert werden und überschreiben dann die ursprünglichen Inhalte.
Die lang_XX.js wird doch immer nach der base_vars.js in Abhängigkeit der Variablen Lang aus der base_vars.js gelesen
Sonnige Grüße
Harald
Hallo Harald,
diese Variablen habe ich in den langXX.js Dateien ja schon definiert und auch übersetzt.
Das Problem hierbei ist, das die Variable [+lang+] ebenfalls in der base_vars.js steht und diese wird mehrmals am Tag neu geschrieben.
Also ist die Sprache immer Deutsch für die gesamte Homepage.
Wenn ich also English will muss ich die Variable aus einer Datei hohlen die nicht ständig mit DE neu geschrieben wird.
Die Variable müsste Außerhalb der base_vars.js stehen, das ist aber nicht der Fall.
Die base_vars.js soll genau so bleiben wie sie regelmäßig neu geschrieben wird.
In Deiner links.html kannst Du über die Flaggen eine Sprache auswählen. Diese Auswahl wird in einer Hilfsvariable (langx) gespeichert. Diese Hilfsvariable wird von Seite zu Seite wie der modus weitergegeben. wenn nun irgendwo die base_vars.js eingelesen wird, wird gleich danach die Variable lang aus der base_vars.js mit dem Inhalt der Hilfsvariable langx überschrieben und schon läuft die ganze Verarbeitung, als wenn in der base_vars.js eine andere Sprache stehen würde.
so nach dem Motto
lese base_vars.js
if ( Lang != langx) {
Lang = langx
lese Übersetzung für StatusCodes
lese Übersetzung für FehlerCodes
}
lese "lang_"+Lang+".js (wobei die Codes auch in der lang_XX.js stehen können)
In der links.html würde die Variable langx mit "DE" initialisiert. Auf diese Weise kann auch eine andere Sprache realisiert werden, es muss nur eine entsprechende lang_XX.js vorgehalten werden. Diese ist dann aber allgemein gültig, da die variablen Daten immer aus der jeweiligen base_vars.js kommen.
Wäre eigentlich auch eine Anwendungsmöglichkeit für ein Cookie, dann muss die langx nicht immer mit Übergeben werden und die Sprache bleibt bis zur Neuauswahl erhalten
Sonnige Grüße
Harald
_________________ Alles meine persönliche Meinung. Ohne Gewähr für Vollständigkeit oder Richtigkeit.
Info: Betreiber
Angemeldet: 05.05.2007
Beiträge: 1093
Wohnort: Region Hannover
Verfasst am:
23.10.2007, 02:08
Captain auroPOWER hat Folgendes geschrieben:
jetzt habe ich verstanden was Du meinst.
Ja, es soll Leute geben die können sich verständlicher ausdrücken als ich
Zitat:
Würde da gerne noch mal drauf zurückkommen, wenn es an die Umsetzung geht, wenn ich darf.
Da meine Java Kennnisse noch absolut jungfreulich sind.
Dann bin ich dir ja 4 Wochen Voraus Muss aber zugeben das ich schon in anderen Sprachen Programmiererfahrung habe.
Gemeinsam lernt es sich besser und manchmal braucht man Andere um zu sehen das Kreise auch dann immer noch rund bleiben wenn sie dicker oder größer sind.
Sonnige Grüße
Harald
_________________ Alles meine persönliche Meinung. Ohne Gewähr für Vollständigkeit oder Richtigkeit.
um das Thema Sprachen wieder aufzugreifen. Problem ist ja, dass die Status/ und Fehlercodes "hart codiert" vom SolarLog geschrieben werden. Und dazu ist das auch noch abhängig, welche WR-Firmware man drauf hat.
Bei SMA kommen die Bezeichnungen aber aus dem Wechselrichter, da hat der SolarLog keinen Einfluss drauf, wie die Texte aussehen. Bei allen anderen aber schon.
Zukünftig will ich das so machen, dass die Status/Fehlercodes in der Sprache geschrieben werden, wie auch die Firmware ist (ausser SMA).
Das hat immerhin den Vorteil, dass der Besitzer "seine" Sprache drin hat. Eine externe Umschaltung per FLagge auf eine andere Sprache ändert daran dann nichts, aber immerhin hat man den Großteil der Homepage-Texte schonmal übersetzt.
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
Die Sprache wird doch als (Hilfs-)Variable mitgeführt, somit bleibt es bei einem Link.
Muss aber zugeben das ich schon in anderen Sprachen Programmiererfahrung habe.
