l10n-merge verwenden

Meistens ist es der Spieltrieb, machmal sind es Sachzwänge wie Bug 756116, gelegentlich Testzwecke – immer wieder ist die Versuchung groß, Kalenderpakete von Sunbird und Lightning selbst zu kompilieren – und zwar bitte schön mit deutschsprachiger Oberfläche, dafür machen wir den Übersetzungskram schließlich.

Einer der zahlreichen möglichen Stolpersteine bei diesem Vorhaben sind die unterschiedlichen Übersetzungsgewohnheiten innerhalb des de-Teams. Denn mit den unterschiedlichen Repositories im Rahmen des RapidRelease-Schemas kann für jedes Produkt aus der Mozilla-Familie an unterschiedlichen Stellen mit der Übersetzung angesetzt werden: Kümmert man sich mit l10n-central auch um die früheste Entwicklung? Oder mit dem  Aurora-Kanal um etwas stabilere Entwicklungsergebnisse? Oder mit dem Beta-Kanal um solche, die es nicht mehr weit bis zur Veröffentlichung haben?  Während der vergleichsweise kleine /calendar/-Zweig meist schon für die ‚central-Familie‘ übersetzt ist, wird die meiste andere Übersetzungsarbeit erst auf dem Aurora-Kanal geleistet. Für die letztendlich veröffentlichten stabilen Versionen ist das völlig egal, für die oben erwähnten Kompilier-Verlockungen allerdings nicht: Wenn z.B. die Thunderbird-Übersetzung auf l10n-central nicht komplett ist, kann von diesem Zweig in aller Regel auch kein deutschsprachiges Lightningpaket gebaut werden, weil der Vorgang dann irgendwann mit Fehlern wegen vermisster Dateien oder Einträge abbricht.

Damit genau das nicht passiert, wurde das Werkzeug l10n-merge erstellt und für diverse Build-Setups von Mozilla-Servern aktiviert. Es ist Teil von compare-locales, einem Script, mit dem man v.a. die Vollständigkeit einer Übersetzung prüfen kann. Mit l10n-merge lassen sich dann fehlende Übersetzungsteile durch englische Pendants ersetzen. Das war doch genau das, was ich zum Bauen deutschsprachiger Thunderbird-/Lightningpakete von comm-central/l10n-central gesucht habe!! Leider ist die Verwendung von l10n-merge nicht so richtig gut dokumentiert oder ich habe die wertvollsten Quellen einfach nicht gefunden – jedenfalls ließ sich die Chose nicht sofort fehlerfrei einrichten. Trotz l10n-merge brach das Kompilieren immer noch wegen fehlender Übersetzungsdateien ab!

Der Clou scheint zu sein, dass l10n-merge zwar fehlende Einheiten innerhalb vorhandener Übersetzungsdateien ergänzt, aber keine ganz fehlenden Übersetzungsdateien neu anlegt. Irgendwo habe ich gelesen, dass das ein Feature sein soll, also so gewollt ist. Ich will es aber nicht so, und daher ist mal wieder ein Skript-Gefrickel (merge-central.sh) entstanden, das eine Art Rundumschlag darstellt, aber eben funktioniert:

#!/bin/bash
 
cd comm-central
cp -r comm-central/mozilla/browser/locales/en-US/* de-merge/de/browser
cp -r comm-central/calendar/locales/en-US/* de-merge/de/calendar
cp -r comm-central/chat/locales/en-US/* de-merge/de/chat
cp -r comm-central/mozilla/dom/locales/en-US/* de-merge/de/dom
cp -r comm-central/mozilla/extensions/irc/locales/en-US/* de-merge/de/extensions/irc
cp -r comm-central/mozilla/extensions/venkman/locales/en-US/* de-merge/de/extensions/venkman
cp -r comm-central/mail/locales/en-US/* de-merge/de/mail
cp -r comm-central/mozilla/mobile/locales/en-US/* de-merge/de/mobile
cp -r comm-central/mozilla/netwerk/locales/en-US/* de-merge/de/netwerk
cp -r comm-central/suite/locales/en-US/* de-merge/de/suite
cp -r comm-central/mozilla/toolkit/locales/en-US/* de-merge/de/toolkit
compare-locales -m enxde comm-central/calendar/locales/l10n.ini . de
compare-locales -m enxde comm-central/mail/locales/l10n-central.ini . de
cp -r de/* de-merge/de
cp -r enxde/* de-merge/de

Was passiert hier?

  • Erst einmal werden alle englischen Sprachdateien, die für’s Kompilieren eine Rolle spielen könnten, in einen Ordner „de-merge“ kopiert. Damit geht mir später keine Datei mehr als fehlend durch die Lappen!
  • Dann wird der Stand der de-Übersetzung mit compare-locales überprüft. Dabei wird auch l10n-merge angewandt, das dafür sorgt, dass um englische Bruchstücke ergänzte Sprachdateien vorübergehend im Ordner „enxde“ abgelegt werden.
  • Anschließend werden alle deutschen Sprachdateien nach „de-merge“ kopiert. Entsprechende englische Dateien werden dabei überschrieben. Dateien, die es als de-Variante noch nicht gibt, bleiben in englischer Sprache erhalten.
  • Zuguterletzt werden die durch l10n-merge erzeugten Dateien aus „enxde“ ebenfalls nach „de-merge“ kopiert. Manche in „de-merge“ schon vorhandene Dateien werden dabei überschrieben, da sie zwar vollständig ins Deutsche übersetzt, aber eben unvollständig waren. Ersetzt werden sie durch die ‚Hybriddateien‘, die deutschen und englischen Text aufweisen.

Für’s Bauen muss ich dann noch meine .mozconfig ändern, die Übersetzungsdateien liegen nun schließlich nicht mehr klassisch in „de“, sondern in „de-merge“: ac_add_options –with-l10n-base=../de-merge

Tja, lang hat’s gebraucht, um etwas ganz Kleines zu verstehen, nämlich den Schalter „-m“ von compare-locales. Aber immerhin komme ich nun wieder einfach an deutschsprachige Lightningpakete, unabhängig von (ganz legitimen) unterschiedlichen Übersetzungsgewohnheiten.

Bot-Bottich

Sein Wachstum sei Amazon ja gegönnt (von arbeitsmarkt- und sozialpolitisch Fragwürdigem während des Weihnachtsgeschäfts einmal abgesehen) – aber EC2 nervt! Was diverse offensichtliche und mit der Tarnkappe reisende Bots hier an Anfragen abliefern und sämtliche Pfade abschnüffeln – igittigitt.
Es hilft also nichts, ein Bot-Bottich muss her, in den die Kameraden IP-abhängig abgewimmelt werden. Probelauf gestartet. Wäre schön, wenn’s klappt.

Bauen von Thunderbird/Lightning/Sunbird: Scripte_v2

Letztes Jahr habe ich etwas zu meiner „choice.sh“ geschrieben, mit der ich mir das Kompilieren so bequem wie möglich machen wollte.
Das Ansinnen ist geblieben, das Script ist im Laufe der Zeit immer mal wieder leicht geändert worden, nicht nur wegen diverser Versionsnummern, die anzupassen waren. Jetzt sind es also zwei Scripte, und für  den Fall, dass irgendjemand irgendetwas damit anfangen kann, seien sie hier kurz vorgestellt (Wie beim letzten Mal: Achtung, WP-Syntax verfälscht hier wohl ein paar Zeichen, für Download siehe unten).

Die „choice.sh“ für die ‚aktuellen‘ Bauaufgaben sieht nun so aus und pfeffert damit auch endlich alle Fehlermeldungen ins Buildlog: „Bauen von Thunderbird/Lightning/Sunbird: Scripte_v2“ weiterlesen

Kleinere Aktualisierungen

Einige Tage nach der letzten großen Update-Runde für Lightning, Thunderbird und SeaMonkey habe ich die Erweiterungen „Calendar Alarm Slider“ (jetzt Version 1.0) und „Custom Calendar Defaults“ (stilles Update, keine Versionsänderung) aktualisiert – allerdings nur mit Blick auf die ausgewiesene Kompatibilität. An den Funktionen hat sich nichts geändert.

Die Downloads finden sich hier.

DRM – Hörspielgenuss mal umständlich

Kürzlich habe ich mir ein paar Hörspiele bei Audible gekauft. Ohne großes Rumüberlegen oder Recherchieren. Hätte ich mal machen sollen. Denn mit dem Ergebnis bin ich überhaupt nicht zufrieden:

Abgesehen von der extra Software, die u.a. wegen des Downloads installiert werden soll, werden die Hörspiele in einem speziellen Format angeboten. Die PR-Abteilung will das in erster Linie als besonderen Beitrag zum Hörgenuss verstanden wissen, man darf darüber aber sicher müde lächeln und beruhigt davon ausgehen, dass das DRM-Konstrukt mich vor allem vom unerlaubten Vervielfältigen abhalten soll.

Das führt nur auch dazu, dass ich mein gekauftes Hörspiel nicht so ohne Weiteres ins Nachbarzimmer streamen kann. Oder auf den gewohnten Wegen verwalten. Und die Krönung: Wenn ich die Dinger wie in der Hilfe empfohlen brenne, wird am Anfang und am Ende ein kurzer Werbetext des Anbieters gesprochen. WER BRAUCHT DAS DENN?! Wer will denn zwischen zwei Folgen einer Hörspielreihe was darüber hören, wo das Ding gekauft wurde?

Richtig, niemand. Und deshalb kaufe ich da auch nichts mehr. Umständlich. Ärgerlich. DRM-fixiert eben. Warum so kompliziert? Andere schaffen’s doch auch, ganz normale MP3s zu verkaufen und dabei nicht pleite zu gehen…

 

Mal wieder: Erweiterung “Custom Calendar Defaults” aktualisiert

“Custom Calendar Defaults” liegt nun in Version 1.0 vor, passend zu Lightning 1.2 für Thunderbird 10 und SeaMonkey 2.7. Wer die Erweiterung schon installiert hatte, sollte mittlerweile eigentlich ein Angebot für’s automatische Update zu sehen bekommen haben.

Neue Features gibt’s nicht, allerdings habe ich die Erweiterung ‚unter der Haube‘ etwas verändert. Kurz gesagt geht es darum, nicht mehr vollständige .js-Dateien von Lightning zu kopieren und dann zu modifizieren, sondern nur ausgewählte, für „Custom Calendar Defaults“ relevante Funktionen. Das reduziert Konfliktpotenzial mit denkbaren anderen Erweiterungen, außerdem wird damit der Aufwand reduziert, den ich in die Pflege der Erweiterung stecken muss – denn Änderungen, die außerhalb besagter relevanter Funktionen liegen, müssen nun nicht mehr in eine neue Version der Erweiterung portiert werden.
An dieser Stelle noch einmal Danke an Philipp für Infos dazu, wie sich das bewerkstelligen lässt.

 

Custom Calendar Defaults 1.0:

Kompatibel mit:
Lightning 1.2 mit Thunderbird 10
Lightning 1.2 mit SeaMonkey 2.7

Die Datei:
CustomCalendarDefaults-1.0-sm+tb.xpi

Die .diff:
0.9_vs_1.0.diff (etwa 6x so groß wie die .xpi selbst *g*)

Renovierung von Custom Calendar Defaults läuft…

*Grrrrr!!!!*

Stundenlang probiert, Philipps Tipp von neulich umzusetzen, nicht ganze Dateien zu kopieren und zu verändern, sondern sich einfach nur gezielt die Funktionen rauszupicken, die für die Erweiterung von Interesse sind. Und natürlich: Nichts ging! Hin und her, her und hin, mal dieser Fehler, mal jener, mal kein Fehler, dafür dann aber auch keine veränderte Funktion!!

Und…? Na…? Woran hat’s wohl gelegen???

Richtig!! Einfach mal das richtige Ziel für’s overlay angeben, in diesem Fall „calendar-views.xul“ – und schon läuft die Sache!! Das kommt davon, wenn man nur auf das Script schielt und die chrome.manifest dafür *huschhusch* abhandelt…

Jetzt geht’s jedenfalls voran.

Erweiterung „Custom Calendar Defaults“ aktualisiert

Autsch, Rapid Release Cycle tut doch weh. Eigentlich war der Plan, dass es nicht zwei Wochen vom Erscheinen einer neuen Mozilla Lightning-Version bis zur passend gemachten Erweiterung dauert – nun ist es doch passiert. Was soll man machen…

„Custom Calendar Defaults“ liegt nun jedenfalls in Version 0.8 vor, passend zu Lightning 1.0 für Thunderbird 8 und SeaMonkey 2.5. Wer die Erweiterung schon installiert hatte, sollte mittlerweile eigentlich ein Angebot für’s automatische Update zu sehen bekommen haben. Auf drei Dinge möchte ich bei dieser Version hinweisen:

  • Vor einigen Wochen wurde der Wunsch geäußert, dass sich doch bitte auch Standardwerte für die Termin-/Aufgabeneigenschaft „Zeit anzeigen als“ (Beschäftigt/Verfügbar) definieren lassen sollten. In Version 0.8 habe ich das versucht einzubauen, im Einstellungen-Dialog findet sich ein entsprechender Abschnitt. Da diese Eigenschaft in iCalender-Dateien (.ics) über „TRANSP:TRANSPARENT“ bzw. „TRANSP:OPAQUE“ übermittelt wird, versucht die Erweiterung das jetzt ebenfalls auf genau diesem Weg. Bei meinen Tests sah das im Termin- bzw- Aufgabendialog gut aus, die jeweilige Option war stets passend zur Voreinstellung markiert. Ob das dann auch im Austausch mit Kalenderservern läuft, die etwas mit dieser Funktion anfangen wollen, müssten dann bitte mal Leute ausprobieren, die mit solchen Servern arbeitern. Ich tue es nicht. 🙂
  • Hatte ich in Version 0.7 aus Versehen die Voreinstellungen für QuickAdd-Aufgaben aus dem Code geschmissen, die in 0.5 noch drin waren? Ich konnte mich an keinen vernünftigen Grund dafür erinnern – jetzt ist der Kram wieder drin. Solche Missgeschicke entstehen, wenn man nur hin und wieder an einer Erweiterung arbeitet… Irgendwie fängt man dann immer beinahe von Neuem an.
  • Achtung, liebe Nutzer von Google-Kalendern: Neuerdings (?) hagelt es „Modification failed“-Fehler, wenn man den Status eines Termins als „Abgebrochen“ zu definieren versucht. Jedenfalls ist das bei mir so (mit dem Provider 0.9). Das bedeutet: Wenn man als Voreinstellung für neue Termine den Status „Abgebrochen“ definiert (warum auch immer man auf so eine Idee kommen sollte!!), dann wird man beim Anlegen neuer Termine in einen Google-Kalender nicht mehr glücklich.
    Ein Status „Nicht angegeben“ wird bei Google übrigens automatisch zu „Bestätigt“ – nix zu machen.

In der nächsten Version wird die Erweiterung möglicherweise etwas kleiner und auch toleranter gegenüber anderen Ergänzungserweiterungen für Lightning: Philipp vom Kalenderprojekt hat mir neulich einen Tipp zukommen lassen, wie ich auch einzelne Funktionen (und nicht mehr ganze .js-Dateien) ersetzen kann. Leider bin ich bisher nicht dazu kommen, den Tipp einmal auszuprobieren… Wird schon noch werden.

So, für den Moment:

Custom Calendar Defaults 0.8:

Kompatibel mit:
Lightning 1.0 mit Thunderbird 8
Lightning 1.0 mit SeaMonkey 2.5

Die Datei:
CustomCalendarDefaults-0.8-sm+tb.xpi

Die .diff:
0.7_vs_0.8.diff

Erweiterung „Custom Calendar Defaults“ erschienen

So, die erste Runde ist raus:
Die Erweiterung „Custom Calendar Defaults“ ist denke ich reif genug, um freigegeben zu werden. Mit ihr lassen sich Standardeinstellungen für neue Termine und Aufgaben feslegen, und zwar Einstellungen für Status, Priorität und Privatsphäre. Die Einstellungen greifen beim Anlegen von

  • Terminen und Aufgaben mit Hilfe des entsprechenden Dialogs,
  • Aufgaben über die „Quick add“-Zeile und
  • Terminen per „Click & Drag“ in Tages- oder Wochenansicht.

Die Einstellungen lassen sich nun über einen Einstellungen-Dialog der Erweiterung konfigurieren. Eine nahtlose Integration in die Lightning-Einstellungen wäre zwar auch hübsch, ist mir jetzt aber zu aufwendig.
Mehr Features gewünscht? An Voreinstellungen für Kategorien bin ich wie bereits erwähnt gescheitert; denkbar wäre für die Zukunft aber z.B. noch eine Beeinflussung des Titels von neuen Einträgen. Es gibt in den Dateien eine Variable „summary“, die sich leicht mit Wunschdaten füttern lassen sollte…

Apropos Zukunft:
Ich hoffe sehr, dass nicht zu viele Erweiterungen dieser Art für Lightning entstehen werden. Denn „Custom Calendar Defaults“ arbeitet mit geringfügig modifizierten Kopien von verschiedenen JavaScript-Dateien von Lightning. Per „override“-Anweisung in der chrome.manifest verwendet Lightning dann nicht mehr die eigenen, sondern die Dateien der Erweiterung. Vermutlich gäbe es Konflikte, wenn andere Erweiterungen auf demselben Weg an denselben Dateien etwas modifizieren wollten…
An dieser Stelle hoffen wir einfach mal. Wenn natürlich jemand ein anderes/einfacheres Verfahren mitteilen möchte, wie man sich in Lightning-Funktionen ‚einklinken‘ und diese modifizieren kann – her damit!

Weil die Erweiterung mit modifizierten Kopien von Lightning-Dateien arbeitet, solche Dateien sich im Laufe der Lightning-Entwicklung aber ändern können, bekommt jedes Lightning-Release seine eigene Version von „Custom Calendar Defaults“ zugewiesen:

  • Custom Calendar Defaults 0.1 für
    Sunbird 1.0b1 bzw. Lightning 1.0b1 + Thunderbird 3.0:
    Download
  • Custom Calendar Defaults 0.2 für
    Sunbird 1.0b2 bzw. Lightning 1.0b2 + Thunderbird 3.1:
    Download
  • Custom Calendar Defaults 0.4 für
    Lightning 1.0b4 + Thunderbird 5 / SeaMonkey 2.1-2.2:
    Download
  • Custom Calendar Defaults 0.5 für
    Lightning 1.0b5 + Thunderbird 6 / SeaMonkey 2.1-2.3:
    Download

Rund um den 27. September ist dann (hoffentlich) die nächste Version verfügbar, denn dann soll eine neue Lightning-Version erscheinen.

Feedback willkommen.

Erweiterung „Custom Calendar Defaults“ in Arbeit

Das wird die letzte Frickel-Aktion dieser Ferien:
Nachdem ich nun kapiert habe, was man mit „override“- an Stelle von „overlay“-Anweisungen so alles über eine Erweiterung erreichen kann, bastele ich an einer Erweiterung für das Setzen individueller Voreinstellungen beim Anlegen neuer Termine oder Aufgaben in Lightning (vgl. Bugs wie 288157 oder 215975).

Mit kleinen Eingriffen in die calendar-item-editing.js lässt sich nun schon für Status, Privatsphäre und Priorität eine gewünschte Voreinstellung konfigurieren, die dann beim Erstellen neuer Einträge entsprechende Werte aus den Prefs ausliest und den Dialog anpasst.

Eigentlich würde ich das gerne auch für die Kategorien hinbekommen, aber hier hat auch viel Basteln bislang nicht weitergeholfen. Die Krönung war der folgende Fehler:

Fehler: uncaught exception: [Exception… „Cannot modify properties of a WrappedNative“  nsresult: „0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)“  location: „JS frame :: chrome://calendar/content/calendar-item-editing.js :: createEventWithDialog :: line 186“  data: no]

Der sagt mir offenbar, dass die Kategorien „tiefer“ im Code verwaltet werden und ich da nicht so einfach was umbiegen kann. Was weiß ich, wann da wo welche Kopien irgendwelcher Objekte oder so angelegt und weiter verwurstet werden. Ist mir zu hoch. Schade. 🙂 Die Kategorien-Geschichte werde ich daher wohl aufgeben.

Vor der Veröffentlichung einer ersten Version von „Custom Calendar Defaults“ muss ich aber mal noch zusehen, dass die individuellen Einstellungen per Einstellungen-Dialog vorgenommen werden können – den gibt’s bisher nicht. Und dann wäre noch zu prüfen, wie sich die Erweiterung bei den ‚abgekürzten‘ Wegen zum Erstellen von Terminen und Aufgaben verhält, wenn also der Dialog nicht erscheint…