Jump to content

SnowHead

Admin
  • Gesamte Inhalte

    36.526
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    95

SnowHead hat zuletzt am 8. Dezember 2016 gewonnen

SnowHead hat die beliebtesten Inhalte erstellt!

Reputation in der Community

169 Excellent

1 Benutzer folgt diesem Benutzer

Über SnowHead

  • Rang
    Admin
  • Geburtstag 23.05.1963

Profile Information

  • Gender
    Male
  • Location
    hab' ich vergessen

Letzte Besucher des Profils

14.710 Profilaufrufe
  1. Ich habe für Übersetzungen für eigene Projekte gute Erfahrungen mit crowdin gemacht. Man muß dann halt nur die richtigen Leute dazu einladen, damit das nicht alles an Einem hängenbleibt. Welche anderen Sprachen noch sinnvoll wären, kann ich nicht einschätzen da ich die Verbreitung des KW-Images nicht so genau kenne.
  2. @Mr.Servo Du kannst davon ausgehen, daß Einträge, die im Leitwolf nicht mehr drin sind wohl aber in anderen locales, nicht mehr benötigt werden. Leerstrings zu füllen kann schiefgehen, wenn die z.B. aus Platzgründen weggelassen wurden. Dann könnte es eng werden mit extra Texten. Die roten Übersetzungen kann man im Prinzip si stehen lassen, nur halt "Info 2" groß und getrennt schreiben. In der Empfehlung von thomasrichter könnte man ggf. "Bookmark" noch durch "Lesezeichen" ersetzen. Wenn sich nicht aus Symbol- oder übersetzem Text ablesen läßt, wo ein Eintrag verwendet wird, kommt man ohne Analyse der Quelltexte nicht weiter. Dazu muß man das Neutrino nicht einmal bauen sondern nur auschecken und mit Eclipse untersuchen. Damit kann man sehr einfach rückverfolgen, in welchen Menüs und Listen die jeweiligen symbolischen Konstanten verwendet werden (und ob überhaupt).
  3. @Mr.Servo Leitwolf ist tatsächlich die english.locale. Diese muß der Imagebauer pflegen und konsistent halten. Fehlt ein Keywort in einer anderssprachigen locale, nimmt Neutrino die zugehörige Übersetzung aus der english.locale. Fehlt das Keywort dort auch, wird statt der Übersetzung das Keywort selbst angezeigt. Deshalb wurden aus Faulheit vermutlich einige Einträge in anderssprachigen locales, die unverändert gegenüber der english.locale sind (z.B. Leerstrings), einfach weggelassen. Ich weiß aber nicht, wieviele solcher Fehleinträge Neutrino insgesamt ausgleichen kann. Ein Leerstring für ein Keywort ist legitim und meistens auch gewollt. Wenn in der aktuellen english.locale Keywörter weggefallen sind und im OSD diese weggefallenen nirgends unübersetzt auftauchen, werden die im aktuellen Image nicht mehr benötigt. Wie gesagt, solange die english.locale vollständig ist tauchen im OSD keine unübersetzten Keywörter auf. Sind auch die anderssprachigen locales konsistent zur english.locale dürften dann auch keine defaultmäßig englisch übersetzten Ausgaben mehr auftauchen.
  4. @Mr.Servo Eigentlich werden die Images und Plugins am einfachsten gleich unter Linux gebaut. Da kommt man nicht in die Verlegenheit, die Zeilenenden einer Linux-Datei (LF) aus Versehen automatisch durch Windows-Zeilenenden (CR+LF) ersetzen zu lassen. Da passiert unter Windows häufiger als man denkt. Als Entwicklungsumgebung unter Linux ist Eclipse sehr gut. Das kann man für die verschiedensten Entwicklungsumgebungen und Compiler anpassen und viele Automatikfunktionen des eingebauten Editors (z.B. automatische Formatierung mit Klammern und Einrückungen) nutzen. Unter Windows verwende ich (wenn erforderlich) den freien Editor Notepad++, den kann man fest auf Linux-Format einstellen. Als FTP-Client verwende ich WinSCP oder den Total Commander. Wichtig bei beiden ist, das Dateiformat für den Transfer keinesfalls auf "Text" oder "Automatisch" zu stellen, dabei gehen viele Linux-Dateien kaputt. Immer das Format "Binär" einstellen.
  5. @Mr.Servo Mach es nicht zu kompliziert. Nicht daß Du mehr Aufwand in die Sache steckst, als eine manuelle Anpassung der paar Textdateien machen würde. Die Quellen des KW-Images sind selbstverständlich nicht öffentlich zugänglich. Wenn Du Dich mit Markham abstimmst, schickt er Dir kurz vor Fertigstellung der nächsten Imageversion sicher gern die deutsch.locale des KW-Images zur Erzeugung der restlichen Sprachdateien. Inzwischen kannst Du ja mit den aktuellen üben und zum Test mal eine italienische oder französische locale erstellen.
  6. @Mr.Servo Ich habe die locale-Beiträge mal in einem neuen Thema zusammengefaßt. Wenn sich, wie Du schreibst englische und deutsche locale in der Zeilanzahl unterscheiden, stimmt irgendwas nicht. Entsprechend dem Verarbeitungsprinzip der locales in den Images müßten die exakt gleich viel Einträge haben. Als Basis für die Ableitung der locales für andere Sprachen ist nach wie vor die deutsch.locale vom Imagebauer vorzuziehen. Die enthält genau die Anzahl Einträge, die das neue Image benötigt. Nicht mehr und nicht weniger. Ausßer den zusätzlichen KW-spezifischen Einträgen muß sie nicht unbedingt mit der im git verfügbaren übereinstimmen, da die sich ja im Vergleich zum Stand des Images beim Auschecken durch den Imagebauer inzwischen ja schon wieder geändert haben kann (und damit nicht mehr zum mit dem Checkout gebauten Image passen würde). Die locales für andere Sprachen (außer englisch, die Markham in der Regel auch schon selbst mit baut (aber sicher auch gern abgeben würde) müßten beim ersten Mal komplett neu aufgebaut werden inklusive der Übersetzungen- Dazu könnten aber als Hilfsmittel die locale anderer Sprachen herangezogen werden, um dort die zu den symbolischen Konstanten gehörenden Übersetzungen herauszuholen und in die eigenen locales einzufügen. Die KW-spezifischen Symbole müßten natürlich mit eigenen Übersetzungen versehen werden. Für spätere Imageversionen müßten dann nur die, wie schon empfohlen, mit Diff gefundenen Änderungen in die bisherigen locales eingepflegt werden.
  7. @Mr.Servo Ich verstehe den Begriff "Maximalliste" nicht. Übersetzungen für alles denkbare und eine Liste mit allen vorstellbaren symbolischen Bezeichnern kann kann es ja noch nicht geben. Im Prinzip ist die z.B. deutsch.locale der jeweils aktuellen Imageversion ja so eine Maximalliste. Die deutsch.locale der gerade in Arbeit befindlichen Imageversion wird ja in der Regel vom Imagebauer erstellt, da nur er weiß, welche symbolischen Konstanten er einfügen oder löschen will. Wenn Du diese neueste locale vom Imagebauer bekommst, kannst Du die mit "diff" gegen die vorherige vergleichen und bekommst sofort angezeigt, welche Zeilen hinzugekommen, weggefallen oder verändert wurden. Nur diese Differenzen müßten dann (natürlich nach Übersetzung der neuen Klartextstrings) in die bestehenden ausländischen locale übernommen werden um sie auf den aktuellen Stand zu bringen. Das würde in meinen Augen den geringsten Aufwand bedeuten. Wenn Du das automatisieren willst, kannst Du ja die Ausgabe von diff per Script analysieren und daraus die Handlungsanweisungen für die anderen locales erzeugen.
  8. Hier liegt ein Mißverständnis vor. Mit dem "Bootloader" hat das gar nichts zu tun. Der ist ein extra geschützer Bereich im Flash, aus welchem beim Start die Routinen aufgerufen werden, welche die erste Hardwareinitialisierung vornehmen und dann das eigentliche Betriebsystem laden. Um auch beim Flashen nicht kaputtgemacht zu werden und so immer eine Möglichkeit zu bieten, auch bei kaputtem Betriebssystem zumindest wieder ein neues Flashen zu können, ist der besonders schreibgeschützt. Wovon hier die Rede war, ist das "Bootlog". Das ist die Ausgabe von Debuginformationen beim Systemstart und -betrieb über die serielle Schnittstelle. Die ist bei den meisten Boxen nicht mehr direkt herausgeführt, sodaß man meist über einen USB<->TTL-Umsetzer von einem internen Stecker in der Box auf den PC verbinden muß, um dieses Log in einem Terrminal auf dem PC anschauen zu können. Mit diesem Log kann man Fehler und Probleme beim Starten gut identifizieren. Um aber mal zu schauen, welche locales Neutrino anmeckert, ist aber nicht mal solch ein Umsetzer nötig. Hier genügt Telnet. Gibt man (nachdem Neutrino auf der Box gestertet ist) in der dann zu öffnenden Telnet-Verbindung vom PC "setconsole" ein, bewirkt dieser nette Befehl, daß die Daten, die bisher auf der seriellen Schnittstelle ausgegeben wurden, nun auf die Telnet-Sitzung umgeleitet werden. Startet man nämlich Neutrino nach "setconsole" über das Service-Menü neu, kann man alle von Neutrino beim Start ausgegebenen Debugmeldungen (einschließlich des eventuellen Gemeckers über nicht passende locale) nun im Telnet verfolgen. Um herauszufinden, was sich von der vorigen zur aktuellen locale geändert hat, kann man beide Dateien mit der Diff-Funktion verschiedenster Editoren oder auch gleich mit dem diff der Box untersuchen. Hier mal testhalber der Vergleich mit dem Diff der Box via Telnet zwischen zwei locales, bei welchem bei der neuen zwei Zeilen hinzugekommen sind (die sind am Anfang mit einem "+" gekennzeichnet: # diff -aBt /tmp/deutsch_alt.locale /share/tuxbox/neutrino/locale/deutsch.locale --- /tmp/deutsch_alt.locale +++ /share/tuxbox/neutrino/locale/deutsch.locale @@ -943,6 +943,7 @@ kw.camd_upd_menu Camd/Cardserver-Update Men kw.cardserver_menu Cardserver Men kw.cardserver_reset Cardserver Reset +kw.channellist_spec Nachfolgesendung (fest) kw.flash_reboot rebooting ... kw.flash_save_settings Aktuelle Settings bernehmen ? kw.flash_saving bernehme Settings @@ -964,6 +965,7 @@ kw.infobar_camd_show Camd-Status anzeigen kw.infobar_ci_show CI-Modul-Status anzeigen kw.infobar_cs_show Cardslot-Status anzeigen +kw.infobar_cw_show CW-Quelle anzeigen kw.infobar_ip_show Sharing-IP anzeigen kw.infobar_mails_show Info ber neue Mails kw.infobar_res_got empfangen
  9. Die Plugins tuxwetter, msgbox, input und shellexec wurden damals im KW-Board für die DBox2 entwickelt, um aus Scripten auf die von diesen Tools angebotenen Funktionen zugreifen zu können. Damals war es noch nicht möglich, eine .so von der Kommandozeile zu starten (das ging nur über ein spezielles weiteres Tool, welches aber die weitere Nutzung durch ein Script nicht zuließ). Deshalb sind diese Tools reine Binaries ohne .so. Nachdem diese von uns ins git gelangten, konnte sich jeder Imageschnitzer seine eigene Version bauen und einige meinten wohl, daß z.B. die shellexec gleich als Shellstarter ausgeführt werden solle, welche zu dem Zeitpunkt auch schon über die Konsole gestartet werden konnten, um das gleichzeitige Vorhandensein von "shellexec" und "shellexec.so" zu vermeiden. Warum auch immer. Die Pfade im KW-Image und den anderen sind historisch so gewachsen. Daß das mal vereinheitlicht werden könnte, glaube ich nicht.. Den Imagenamen kann man in jedem vernünftig gepflegten Image über "cat /.version | grep imagename | cut -d'=' -f2" abfragen.
  10. @Mr.Servo Du hast mein Post oben leider nicht korrekt gelesen. Der Aufruf im Script muß "shellexec" ohne ".so" und ohne Pfadangabe lauten. Wie gesagt, ist die shellexec.so nur ein Shellstarter, welcher die shellexec ohne Übernahme von Parametern mit der standardmäßigen config, also dem KW-Menü startet. Der Aufruf muß lauten "shellexec /tmp/bundesland.conf > /dev/null" So hatte ich das im Script geändert und so lief das bei mir auch. Edit: Da war Markham ein paar Sekunden schneller
  11. @Zapt Ja, 16 Jahre seit dem Tuxwetter-Script und 6 Jahre seit Deinem letzten Posting. ;-b
  12. @Mr.Servo Ist im Prinzip richtig. Um aber einen Eintrag für eine Änderung schnell wiederzufinden (auch der Neutrinobauer muß ja wissen, wie die symbolische Konstante heißt) sollte der erste Teil der Zeile schon besser mit der Symbolliste in den Quellen übereinstimmen. Da Markham die Images für die verschiedenen Boxen aus den gleichen Quellen baut, wird in der Regel eine Version der locales je Imagerelease gebraucht. Da die Sprachen aber auch nachträglich online nachrüstbar sind, könnte man z.B. auch schon mit dem aktuellen Image anfangen. ;-)
  13. @Mr.Servo Ich habe das Plugin mal nach /tmp gepackt, die drei shellexec-Aufrufe angepaßt und ganz oben "set -x" zum Aktivieren der Debugausgabe aingefügt. Scripte, welche msgbox, shellexec oder input verwenden, können nicht über die Konsole aufgerufen werden., da sich sonst Script und Neutrino gleichzeitig um die Fernbedienungseingaben und den Framebuffer für die Grafikausgabe prügeln. Das geht schief. Solche Scripte immer aus Neutrino heraus aufrufen. Im KW-Image genügt dazu eine zusätzliche Zeile in "/var/tuxbox/config/flexinc/my_plugin_run.mnu". Für mein Beispiel in der Form ACTION=§Vodafone,/tmp/vodafone.sh Dann kann das aus dem KW-Menü heraus aufgerufen werden. Um zu sehen, was es tut, öffnet man eine Telnet-Konsole und gibt dort ein "setconsole". Nun werden alle Ausgaben von Neutrino und von Scripten im Telnet mitgeloggt. Bei mir sah das dann so aus: und brachte diese Bildschirmausgaben:
  14. @Mr.Servo Die locales liegen auf der Box in "/share/tuxbox/neutrino/locale". Benannt sind sie nach der jeweils enthaltenen Sprache. Dieser Name taucht dann auch im Sprachenauswahlmenü der Einstellungen auf. Der Aufbau ist einfach. Jede Zeile enthält einen symbolischen Namen, welcher von der Texterzeugung im Neutrino sprachneutral verwendet und bei der Ausgabe durch den hinter dem symbolischen Namen stehenden Text ersetzt wird. Somit ist eine Sprachumschaltung leicht, da sich die jeweiligen symbolischen Namen in allen Sprachdateien wiederfinden. Diese Dateien sind allerdings für jedes Image und jede Imageversion fest angepaßt und nicht untereinander austauschbar, da Neutrino leider beim Ersetzen nicht nach dem symbolischen Namen in der Datei selbst sucht sondern nur die Zeile der Datei verwendet, an deren Position dieser Name in einer internen Liste steht. Das heißt Reihenfolge und Position der einzelnen Zeilen sind vom jeweiligen Image her fest vorgegeben und dürfen nicht geändert werden, sonst wird bei der Textausgabe Müll erzeugt. Die locale (deutsch oder englisch) des jeweils in Arbeit befindlichen Images wird Dir Markham sichern gern kurz vor der Fertigstellung des Images zusenden.
  15. @Mr.Servo "shellexec.so" ist nur ein sogenannter "Shellstarter", welcher es ermöglicht, die shellexec aus Neutrino heraus aufrufen zu können. Das Hilfsprogramm "shellexec" selbst liegt im KW-Image in /bin. Für den Aufruf der shellexec am besten alle Pfadangaben vorher weglassen, da sie in einem Pfad liegt, in welchem beim Aufruf vom System von vornherein nachgesehen wird. Und ohne ".so" am Ende. Also z.B. nur shellexec /tmp/bundesland.conf > /dev/null
×
×
  • Neu erstellen...