Lightbeam nicht mehr zu scrollen, Firefox 34 Versionsfehler?

Zitat von bigpen

Ich bleibe bei der milupo-lightbeam 1.1.0. Hier habe ich einen funktionierenden Schieber, der bei der 1.1.2 fehlt und bin voll zufrieden damit.

Hallo bigpen,

wo gibt's denn die 1.1.2? Du verwechselst das sicherlich mit der älteren 1.0.10.2.

Zitat von milupo

Hallo bigpen,

wo gibt's denn die 1.1.2? Du verwechselst das sicherlich mit der älteren 1.0.10.2.

Du hast natürlich recht. Diese Nummerei bringt mich durcheinander ...

Einfach gesagt, ich benütze wieder deine ursprüngliche, eingedeutschte Version. Aber sie ist definitiv kaum mehr brauchbar. Das liegt aber nicht an dir, sondern an den Herstellern der Erweiterung.

Eigentlich können wir nur noch warten und und hoffen.

Hallo zusammen.
Es ist mittlerweile Version 1.1.1 verfügbar.
Damit sollten die Probleme mit dem Scrollen behoben sein.
Milupo habe ich schon informiert.

Quelle: https://addons.mozilla.org/de/firefox/add…/versions/1.1.1

Mfg.
Endor

Hi,

wie in Beitrag: #11, #16, von mir schon beschrieben; "Darüber hinaus werden unten im Fenster 3 Zeilen überlappend ineinander eingeblendet!
Edit:
Es werden dabei die Text-Bezeichnungen/grauer Leisten-Hintergrund der Liste noch einmal nach unten direkt über die Trennlinie gesetzt."

Mal wieder nur hier bei mir? :shock:

Und das löschen der markierten Links wie von bigpen in Beitrag #10 beschrieben funktioniert mit der neuen Lb 1.1.1 org in englisch auch noch nicht.
Also immer noch mit Fehlern behaftet. :cry:

Klingt so, als ob es sich nicht lohnen würde, eine Übersetzung für die Version 1.1.1 zu machen.

Grüße
milupo

Wegen solcher Zicken im Vorfeld ist die Erweiterung hier schon vor Monaten geflogen...

Zitat von milupo

Klingt so, als ob es sich nicht lohnen würde, eine Übersetzung für die Version 1.1.1 zu machen.

Bei mir scheint alles in Ordnung zu sein. Wie gesagt, ich bevorzuge mehr den optischen Teil.
Jedenfalls sind Hilfe und Infos bei mir von oben bis unten, wenn nötig mit scrollen, samt den Buttons unten, sichtbar.
Hast du die deutschen Texte irgendwie blockweise gespeichert und musst sie nur noch irgendwo einsetzen? Wenn nein (ich blicke da nicht durch), würde ich noch warten damit.

Zitat von Revox

Und das löschen der markierten Links wie von bigpen in Beitrag #10 beschrieben funktioniert mit der neuen Lb 1.1.1 org in englisch auch noch nicht.
Also immer noch mit Fehlern behaftet.

Könnte das nicht sogar Absicht sein, dass man Teile nicht löschen kann, habe ich mir überlegt? Im Grafischen ist das ja auch nicht möglich und irgendwie ergibt es auch keinen Sinn ...

Bis jetzt bin ich eigentlich zufrieden damit.

Zitat von bigpen

Hast du die deutschen Texte irgendwie blockweise gespeichert und musst sie nur noch irgendwo einsetzen? Wenn nein (ich blicke da nicht durch), würde ich noch warten damit.

Nein, ich habe mich noch nicht damit beschäftigt, wie ich Addon-SDK-Dateien lokalisierbar machen kann. Die englischen Strings sind in den .js-Dateien hardcodiert und ich habe sie lediglich durch die deutschen ersetzt.

Zitat

Könnte das nicht sogar Absicht sein, dass man Teile nicht löschen kann, habe ich mir überlegt? Im Grafischen ist das ja auch nicht möglich und irgendwie ergibt es auch keinen Sinn ...

Ich bin auch fast der Meinung. In den Zeilen 660 bis 663 der Datei resources/lightbeam/data/list.js wird der deselect-Handler hinzugefügt, sprich der Handler für die Entfernung einer Auswahl bzw. Markierung. Und genau das wird getan. Auch ich denke deshalb, das es sich hier um keinen Bug handelt, sondern um ein Feature:

// Add handler to deselect rows
    document.querySelector('.deselect').addEventListener('click', function (event) {
      resetSelectedRows();
    }, false);

Grüße
milupo

Zitat von ReVox

wie in Beitrag: #11, #16, von mir schon beschrieben; "Darüber hinaus werden unten im Fenster 3 Zeilen überlappend ineinander eingeblendet!
Es werden dabei die Text-Bezeichnungen/grauer Leisten-Hintergrund der Liste noch einmal nach unten direkt über die Trennlinie gesetzt."
Und das löschen der markierten Links wie von bigpen in Beitrag #10 beschrieben funktioniert mit der neuen Lb 1.1.1 org in englisch auch noch nicht.

Die beiden obigen Fehler kann ich nicht bestätigen. Tritt das nur bei deiner 31 ESR auf oder auch bei der 34.0? Stelle mal einen Screenshot ein.

Und bei dem dritten "Fehler" denke ich mittlerweile, dass es so gewollt ist, dass die Einträge der Liste nur abgewählt werden (siehe meine Nachricht oben) - es kann sein, dass sie früher versteckt wurden, wenn sie nicht ausgewählt waren.

Grüße
milupo

Zitat von Bernd.

Hast du dich eigentlich schon mal mit

beschäftigt?
Damit dürften mMn die Übersetzungen in der json verknüpft sein.

Danke Bernd, ich müsste selbst was zusammenbauen. Normalerweise müsste es eine Datei en-us.json oder en-us.proprties geben, die sämtliche lokalisierbare Strings enthält. Die gibt es nicht. Alle Strings sind in js-dateien hardcodiert und müssen mühevoll herausgezogen werden. Und das bei einer Erweiterung, die offiziell von Mozilla in besonderer Weise unterstützt wird. Eine Schande!

Zitat

aus

wird in der de.json

Wie gesagt, ich habe mich noch nicht groß damit beschäftigt, eine de.json habe ich bloß wegen zwei Strings aus der harness-options.json mal angelegt, mehr aus Neugier wie das funktioniert.

Zitat

Wo das fehlt, könnte man das experimentell hinzufügen, zB

Code

<menuitem label="Daily" value="daily"/>
        <menuitem label="Weekly" value="weekly"/>
        <menuitem label="Recent" value="recent"/>
        <menuitem label="Last 10 sites" value="last10sites"/>

Für die Scripte müsste man das dann wieder auf die herkömmliche Weise via DTD und &Uebersetzung; im chrome-ordner hinzufügen. Jedenfalls sind alle Erweiterungen mit Übersetzung so aufgebaut.

Ja, das betrifft aber nur die paar Strings aus der Datei options.xul. Das sind aber die wenigsten, sechs um genau zu sein, bis auf einer nur einzelne Worte.

Zitat

HTML via message.properties

Code

<title data-i18n="dashboardName"></title>

Zuordnung dann über eine "i18n.js"
--> https://www.camp-firefox.de/forum/viewtopi…=950393#p950393

Das gucke ich mir mal an.

Zitat

Ider du suchst dir eine andere Erweiterung, die mit dem JDK aufgebaut ist.

Na ja, das habe ich auch schon versucht, aber jede Erweiterung ist anders. Und vor allem hat sich kaum jemand Gedanken zur Lokalisierbarkeit gemacht, jedenfalls nicht, solange es den Add-on-SDK-Buiilder gab, denn damit konnte man eine Erweiterung gar nicht lokaliserbar machen. Das geht zwar mit dem Add-on-SDK selbst, aber wohl nur über die Kommandezeile. Das ist mir ehrlich gesagt zuviel Hardcore.

Grüße
milupo

Zitat von milupo

Alle Strings sind in js-dateien hardcodiert und müssen mühevoll herausgezogen werden. Und das bei einer Erweiterung, die offiziell von Mozilla in besonderer Weise unterstützt wird. Eine Schande!

Da von einer Schande zu sprechen ist schon ein sehr hartes Urteil. Dass das Add-on von Mozilla ist, bedeutet ja nicht automatisch, dass es übersetzt sein muss. Und wenn bislang keine Übersetzung vorgesehen ist, dann gibt es auch keinen Grund für Mozilla, eine Pseudo-Übersetzung anzulegen, das bringt ja dann nichts. Viel mehr ist es doch so: Lightbeam ist wie das meiste bei Mozilla Open Source. Ich würde fast wetten, dass ein entsprechender Pull Request, der die Übersetzung offiziell ermöglicht, angenommen würde.

Zitat von milupo

Und vor allem hat sich kaum jemand Gedanken zur Lokalisierbarkeit gemacht, jedenfalls nicht, solange es den Add-on-SDK-Buiilder gab, denn damit konnte man eine Erweiterung gar nicht lokaliserbar machen. Das geht zwar mit dem Add-on-SDK selbst, aber wohl nur über die Kommandezeile. Das ist mir ehrlich gesagt zuviel Hardcore.

Man benötigt die Kommandozeile zum Kompilieren des Add-ons, ja. Ein Vorgang, der unabhängig von der Lokalisierung notwendig ist, damit man ein installierbares Add-on erhält. Für den Vorgang des Übersetzens selbst benötigt man die Kommandozeile nicht. Wenn du es testen willst, wirst du es natürlich kompilieren müssen. Aber das ist alles andere als "hardcore", ein paar Zeilen in die Kommandozeile einzugeben, die eh in der Dokumentation stehen, das lernt man wirklich sehr schnell. Die einzige Herausforderung dürfte wenn überhaupt die Installation der Abhängigkeiten sein, weil das auf Windows im Allgemeinen nicht immer problemlos ist. Ob speziell Python auf Windows zu installieren problematisch ist, weiß ich nicht, auf OS X ist das sowieso standardmäßig installiert. Ansonsten muss nur das SDK heruntergeladen werden, da kann nicht viel bei schief gehen.

Zitat von Sören Hentzschel

Da von einer Schande zu sprechen ist schon ein sehr hartes Urteil. Dass das Add-on von Mozilla ist, bedeutet ja nicht automatisch, dass es übersetzt sein muss. Und wenn bislang keine Übersetzung vorgesehen ist, dann gibt es auch keinen Grund für Mozilla, eine Pseudo-Übersetzung anzulegen, das bringt ja dann nichts. Viel mehr ist es doch so: Lightbeam ist wie das meiste bei Mozilla Open Source. Ich würde fast wetten, dass ein entsprechender Pull Request, der die Übersetzung offiziell ermöglicht, angenommen würde.

Es geht mir nicht um eine Übersetzung, sondern um die Lokalisierbarkeit. Es gehört sich einfach, dass einem Übersetzer die nötigen Strings zur Verfügung gestellt werden, also die originalen englischen Strings, ohne dass man erst Kopfstände machen muss. Bisher ging es doch auch - mit dtd- und properties-Dateien. Und jetzt braucht man - wenn ich das richtig verstehe sogar nur einen Dateityp, etnweder json oder properties. Was ist also so schwer daran, eine Locale-Datei mit den englischen Strings mitzuugeben!

Zitat

Man benötigt die Kommandozeile zum Kompilieren des Add-ons, ja. Ein Vorgang, der unabhängig von der Lokalisierung notwendig ist, damit man ein installierbares Add-on erhält. Für den Vorgang des Übersetzens selbst benötigt man die Kommandozeile nicht. Wenn du es testen willst, wirst du es natürlich kompilieren müssen. Aber das ist alles andere als "hardcore", ein paar Zeilen in die Kommandozeile einzugeben, die eh in der Dokumentation stehen, das lernt man wirklich sehr schnell. Die einzige Herausforderung dürfte wenn überhaupt die Installation der Abhängigkeiten sein, weil das auf Windows im Allgemeinen nicht immer problemlos ist. Ob speziell Python auf Windows zu installieren problematisch ist, weiß ich nicht, auf OS X ist das sowieso standardmäßig installiert. Ansonsten muss nur das SDK heruntergeladen werden, da kann nicht viel bei schief gehen.

Das ist aber alles nicht nötig, wenn die Autoren der jeweiligen Erweiterung eine Datei mit den englischen Strings zur Verfügung stellen. Nochmal die Frage, was ist so schwer daran? Soll denn jeder Übersetzer erst einmal Python und das SDK herunterladen und installieren? Dann soll er die Erweiterung nochmal kompilieren und sich dann ein eigenes Locale zusammenbauen und das bei jeder neuen Version wieder und wieder? Es ist nicht Sache der Übersetzer sich darum zu kümmern. Es ist Sache der Autoren. Und es ist Sache von Mozilla, die Bedingungen dafür zu schaffen, dass die Autoren das vorbereiten können.

Grüße
milupo

Zitat von milupo

Die beiden obigen Fehler kann ich nicht bestätigen. Tritt das nur bei deiner 31 ESR auf oder auch bei der 34.0? Stelle mal einen Screenshot ein.

Und bei dem dritten "Fehler" denke ich mittlerweile, dass es so gewollt ist, dass die Einträge der Liste nur abgewählt werden (siehe meine Nachricht oben) - es kann sein, dass sie früher versteckt wurden, wenn sie nicht ausgewählt waren.

Grüße
milupo

Hallo milupo,
Habe extra den FF 34.05 nackend und nur diese eine Erweiterung Lightbeam 1.1.1 org von AMO installiert.

2x Auf den List-Button geklickt.
Ergebnis siehe Screen:
[Blockierte Grafik: http://abload.de/thumb/screenligthbeam1.1.1ixml80.png]
genauso siehts in der 31.3.0-ESR auch aus.

Zitat von ReVox

[
Hallo milupo,
Habe extra den FF 34.05 nackend und nur diese eine Erweiterung Lightbeam 1.1.1 org von AMO installiert.
2x Auf den List-Button geklickt.
Ergebnis siehe Screen:genauso siehts in der 31.3.0-ESR auch aus.

Hm, da bist du wohl der Einzige. Kann es sein, dass du eventuell schon Multiprocessing (e10s) aktiviert hast? Lightbeam ist noch nicht kompatibel, da es noch einen Bug gibt:

https://bugzilla.mozilla.org/show_bug.cgi?id=1053007

Dazu die Liste der kompatiblen Add-ons:

http://arewee10syet.com/

Vielleicht liegt es daran.

Grüße
milupo

Zitat von milupo

Es geht mir nicht um eine Übersetzung, sondern um die Lokalisierbarkeit. Es gehört sich einfach, dass einem Übersetzer die nötigen Strings zur Verfügung gestellt werden, also die originalen englischen Strings, ohne dass man erst Kopfstände machen muss. Bisher ging es doch auch - mit dtd- und properties-Dateien. Und jetzt braucht man - wenn ich das richtig verstehe sogar nur einen Dateityp, etnweder json oder properties. Was ist also so schwer daran, eine Locale-Datei mit den englischen Strings mitzuugeben!

Es geht doch gar nicht darum, ob das schwer ist. Die Frage ist: sind bislang Übersetzungen vorgesehen, ja oder nein? Und die Antwort ist Nein, also gibt es auch überhaupt keinen Grund, alles in Sprachvariablen auszulagern. Wenn du eine übersetzte Version anbieten möchtest, dann ist das toll für alle, welche diese Version nutzen wollen, nur wird die Übersetzung halt nicht offiziell angeboten und ist damit nunmal nicht Sache der Lightbeam-Entwickler. Wie gesagt, ich glaube schon, dass ein entsprechender Pull Request angenommen würde, bislang hat das aber niemand zu Lightbeam beigetragen. Außerdem hört das ja nicht bei übersetzten Strings auf. Es gibt ein Issue auf GitHub zu dem Thema und da war davon die Rede, dass die eigentliche Schwierigkeit ist, dass Grafiken mit Text existieren, die kann man nicht so einfach übersetzen. Ich hab jetzt nicht überprüft, wie aktuell das noch ist, aber wenn die Lightbeam-Entwickler eine offizielle Übersetzung anbieten, dann ganz sicher keine halbe, sondern nur eine vollständige. Denn etwas nicht anzubieten ist meistens besser als einen Mischmasch anzubieten.

Zitat von milupo

Das ist aber alles nicht nötig, wenn die Autoren der jeweiligen Erweiterung eine Datei mit den englischen Strings zur Verfügung stellen. Nochmal die Frage, was ist so schwer daran? Soll denn jeder Übersetzer erst einmal Python und das SDK herunterladen und installieren? Dann soll er die Erweiterung nochmal kompilieren und sich dann ein eigenes Locale zusammenbauen und das bei jeder neuen Version wieder und wieder? Es ist nicht Sache der Übersetzer sich darum zu kümmern. Es ist Sache der Autoren. Und es ist Sache von Mozilla, die Bedingungen dafür zu schaffen, dass die Autoren das vorbereiten können.

Wie ich schon sagte, Übersetzungen sind bislang nicht vorgesehen. Und wären Übersetzungen vorgesehen, dann bräuchtest du auch kein Python und kein SDK, dann müsstest du doch auch nur die Datei übersetzen und das Add-on wieder zu einer XPI-Datei packen. Neue Übersetzungen fügst du ganz einfach hinzu, indem du eine neue json-Datei in /locales/ hinzufügst und den Sprachcode in locales.json ergänzt. Das ist nicht schwieriger als bei Nicht-SDK-Erweiterungen. Wenn bei XUL-Erweiterungen keine Übersetzungen vorgesehen sind, dann benötigst du da vielleicht kein Python, aber auch ein bisschen Handarbeit, um die Übersetzbarkeit vorzubereiten. Das dauert bei SDK-Erweiterungen sicher nicht bedeutend länger und ist auch nicht schwieriger. Man muss sich eben einmalig fünf Minuten Zeit nehmen, um das System einzurichten, das ist dann aber für immer eingerichtet. Naja, für immer mit Einschränkung. Wenn Firefox 37 final ist, dann könnte man auf JPM statt cfx als Tool umsteigen, cfx wird es möglicherweise nicht für immer geben, und erst dann wird man JPM-Erweiterungen auf AMO hochladen können. Dafür wäre die Voraussetzung dann halt nicht Python, sondern node.js.

Zitat von Sören Hentzschel

Es geht doch gar nicht darum, ob das schwer ist. Die Frage ist: sind bislang Übersetzungen vorgesehen, ja oder nein? Und die Antwort ist Nein,

Daran schließt sich unwillkürlich die Frage an: Warum nicht?
Man sollte sich bei Mozilla einfach mal davon verabschieden alles und jedes nur auf die englische Weltsprache festzulegen.
Also andersherum wirds vernünftig... in Zukunft daran denken, das Übersetzungen vorgesehen werden.. :wink:

Zitat von Sören Hentzschel

Es geht doch gar nicht darum, ob das schwer ist. Die Frage ist: sind bislang Übersetzungen vorgesehen, ja oder nein? Und die Antwort ist Nein, also gibt es auch überhaupt keinen Grund, alles in Sprachvariablen auszulagern. Wenn du eine übersetzte Version anbieten möchtest, dann ist das toll für alle, welche diese Version nutzen wollen, nur wird die Übersetzung halt nicht offiziell angeboten und ist damit nunmal nicht Sache der Lightbeam-Entwickler.
Wie gesagt, ich glaube schon, dass ein entsprechender Pull Request angenommen würde, bislang hat das aber niemand zu Lightbeam beigetragen.

Es ist doch wohl das normalste von der Welt, dass Nutzer von Erweiterungen die Erweiterungen in ihrer Sprache nutzen wollen. Und das ist ja auch bei anderen Erweiterungen schon lange gängige Praxis. Wir leben schließlich in einer globalen Welt. Und auch in der Mozilla-Welt ist das sonst nicht anders. Du meinst also, dass die Autoren von Lightbeam das bewusst verhindern wollen? Warum sollten sie das tun?

Zitat

Außerdem hört das ja nicht bei übersetzten Strings auf. Es gibt ein Issue auf GitHub zu dem Thema und da war davon die Rede, dass die eigentliche Schwierigkeit ist, dass Grafiken mit Text existieren, die kann man nicht so einfach übersetzen. Ich hab jetzt nicht überprüft, wie aktuell das noch ist, aber wenn die Lightbeam-Entwickler eine offizielle Übersetzung anbieten, dann ganz sicher keine halbe, sondern nur eine vollständige. Denn etwas nicht anzubieten ist meistens besser als einen Mischmasch anzubieten.

Ich habe schon mal geschrieben, die Entwickler brauchen keine Übersetzungen anbieten, sie sollen nur die Voraussetzung dafür schaffen, dass man Übersetzungen machen kann, sie sollen Lightbeam lokalisierbar machen. Mit Bugs kann man umgehen. Und was heißt hier Grafik mit Text? Das sollten die Lightbeam-Autoren eigentlich wissen, dass man Grafik mit Text vermeiden sollte, es sei denn es handelt sich um unveränderlichen Text, wie zum Beispiel bei einem Logo. Das ist ein Problem, das man von vornherein vermeiden kann.

Zitat

Wie ich schon sagte, Übersetzungen sind bislang nicht vorgesehen. Und wären Übersetzungen vorgesehen, dann bräuchtest du auch kein Python und kein SDK, dann müsstest du doch auch nur die Datei übersetzen und das Add-on wieder zu einer XPI-Datei packen. Neue Übersetzungen fügst du ganz einfach hinzu, indem du eine neue json-Datei in /locales/ hinzufügst und den Sprachcode in locales.json ergänzt. Das ist nicht schwieriger als bei Nicht-SDK-Erweiterungen.

Davon brauchst du mich nicht zu überzeugen, das ist ja das was ich will. Wie die lokalisierbare Version dann aussieht, ist mir egal, Hauptsache, sie ist einfach lokaliserbar, wie bisher bei anderen Erweiterungen auch. Stattdessen rechtfertigst aber immer wieder die nicht zufriedenstellende derzeitige Situation.

Zitat

Wenn bei XUL-Erweiterungen keine Übersetzungen vorgesehen sind, dann benötigst du da vielleicht kein Python, aber auch ein bisschen Handarbeit, um die Übersetzbarkeit vorzubereiten. Das dauert bei SDK-Erweiterungen sicher nicht bedeutend länger und ist auch nicht schwieriger. Man muss sich eben einmalig fünf Minuten Zeit nehmen, um das System einzurichten, das ist dann aber für immer eingerichtet.

Du brauchst mir nicht erzählen, wie das bei XUL-Dateien ist. Du weißt selbst, dass Endor und ich hier schon länger Übersetzungen nachreichen und dabei die Erweiterungen auch etwas anpassen müssen und somit genau diese Handarbeit machen, von der du redest. Aber letzteres ist das Anpassen nicht unsere Aufgabe. Wir haben es uns zur Aufgabe, gemacht fehlende oder unvollständige Übersetzungen zur Verfügung zu stellen. Und du weißt selbst, dass es sich da nicht bloß um fünf Minuten handelt. Auch bei XUL nicht. Nicht bei reiner Übersetzungsarbeit und erst recht nicht, wenn ich mir mein System hier erst passend machen muss, selbst wenn es bloß einmalig ist.

Zitat

Naja, für immer mit Einschränkung. Wenn Firefox 37 final ist, dann könnte man auf JPM statt cfx als Tool umsteigen, cfx wird es möglicherweise nicht für immer geben, und erst dann wird man JPM-Erweiterungen auf AMO hochladen können. Dafür wäre die Voraussetzung dann halt nicht Python, sondern node.js.

Das interessiert alles nicht. Die Voraussetzungen zu schaffen ist nicht die Sache der Übersetzer, sondern der Erweiterungsautoren und von Mozilla. Hätte, könnte, sollte, wollte .. das bringt doch alles nichts.

Zitat von milupo

Es ist doch wohl das normalste von der Welt, dass Nutzer von Erweiterungen die Erweiterungen in ihrer Sprache nutzen wollen. Und das ist ja auch bei anderen Erweiterungen schon lange gängige Praxis. Wir leben schließlich in einer globalen Welt. Und auch in der Mozilla-Welt ist das sonst nicht anders. Du meinst also, dass die Autoren von Lightbeam das bewusst verhindern wollen? Warum sollten sie das tun?

Nein, genau das sage ich nicht. Meine Aussage ist, dass Lokalisierung bislang nicht auf der Liste der Features von Lightbeam steht, weil es bislang eben keine Priorität für die Lightbeam-Entwickler war. Und solange sie selbst keine Übersetzungen anbieten, kann man auch nicht verlangen, dass alles in Sprachvariablen ausgelagert wird, weil das vollkommmen sinnlos wäre, wenn man keine Übersetzung anbietet, diese Forderung ist einfach unrealistisch.

Ich wiederhole mich: Lightbeam ist Open Source und in all den Monaten hätte längst jemand einen Pull Request einreichen können, das ist aber nicht geschehen. Ob dieser dann angenommen worden wäre, oder nicht, würde man dann sehen. Aber ich denke persönlich nicht, dass etwas dagegen sprechen würde. Nur: Wenn Mozilla selbst bislang keine Übersetzung anbietet, dann müssen sie selbst auch keine Ressourcen investieren. Die Menschen, die für Mozilla daran arbeiten, die haben auch nicht unendlich Ressourcen, die haben auch noch andere Aufgaben. Nimm zun Beispiel Monica Chew, von der einige Commits im GitHub-Repository kommen. Lightbeam ist nicht ihre einzige Baustelle, sie ist auch sehr aktiv, was den in Firefox integrierten Tracking-Schutz betrifft (Polaris-Projekt). Du darfst einfach nicht davon ausgehen, dass die Menschen, die daran arbeiten, das alles in ihrer Freizeit aus Langeweile machen. Das sind Menschen, die ihrem Beruf nachgehen. Sie werden dafür bezahlt, bestimmte Aufgaben zu erledigen und wenn etwas auf einer Produkt-Roadmap nicht so weit oben steht wie andere Dinge, dann werden diese Dinge auch nicht vor den anderen Dingen erledigt. Dann muss eben die Community mithelfen, wenn da ein Bedarf besteht.

Zitat von milupo

Ich habe schon mal geschrieben, die Entwickler brauchen keine Übersetzungen anbieten, sie sollen nur die Voraussetzung dafür schaffen, dass man Übersetzungen machen kann, sie sollen Lightbeam lokalisierbar machen. Mit Bugs kann man umgehen. Und was heißt hier Grafik mit Text? Das sollten die Lightbeam-Autoren eigentlich wissen, dass man Grafik mit Text vermeiden sollte, es sei denn es handelt sich um unveränderlichen Text, wie zum Beispiel bei einem Logo. Das ist ein Problem, das man von vornherein vermeiden kann.

Das ist nicht der Punkt in meiner Aussage gewesen, auf den ich hinauswollte. Ich wollte darauf hinaus, dass ein halbübersetztes Produkt als schlechter eingeordnet werden kann als ein gar nicht übersetztes Produkt. Und es ist eben nicht damit getan, nur ein paar Zeilen Text zu übersetzten, sprich es müsste möglicherweise zunächst ein Teil des Add-ons umgebaut werden, bevor es überhaupt Sinn ergibt, Übersetzungen zu ermöglichen, denn wenn Übersetzungen angeboten werden - egal ob offziell oder nicht - sollte sie auch vollständig sein.

Zitat von milupo

Davon brauchst du mich nicht zu überzeugen, das ist ja das was ich will. Wie die lokalisierbare Version dann aussieht, ist mir egal, Hauptsache, sie ist einfach lokaliserbar, wie bisher bei anderen Erweiterungen auch. Stattdessen rechtfertigst aber immer wieder die nicht zufriedenstellende derzeitige Situation.

Ich rechtfertige überhaupt keine Situation, ich behandle das Thema auf einer viel höheren, allgemeineren Ebene. Mir geht es um etwas, was für ausnahmslos alle Add-ons gilt: Wenn der Hersteller keine Übersetzung anbietet, dann kann man nicht verlangen, dass der Hersteller Texte in Sprachvariablen auslagert. Du hast in diesem Zusammenhang von "Schande" gesprochen und dem muss ich einfach entschieden widersprehen, das ist ein ziemlich starkes Wort für etwas, was aus Sicht der Lightbeam-Entwickler einfach keinen Sinn ergibt, da es null Gewinn bringt. Wenn du eine übersetzte Version in einem privaten Forum anbieten möchtest, dann ist die Vorbereitung dafür wirklich nicht Mozillas Aufgabe. Da verlangst du sehr viel.

Zitat von milupo

Du brauchst mir nicht erzählen, wie das bei XUL-Dateien ist. Du weißt selbst, dass Endor und ich hier schon länger Übersetzungen nachreichen und dabei die Erweiterungen auch etwas anpassen müssen und somit genau diese Handarbeit machen, von der du redest. Aber letzteres ist das Anpassen nicht unsere Aufgabe. Wir haben es uns zur Aufgabe, gemacht fehlende oder unvollständige Übersetzungen zur Verfügung zu stellen. Und du weißt selbst, dass es sich da nicht bloß um fünf Minuten handelt. Auch bei XUL nicht. Nicht bei reiner Übersetzungsarbeit und erst recht nicht, wenn ich mir mein System hier erst passend machen muss, selbst wenn es bloß einmalig ist.

Ich habe in meinem Beitrag ja auch überhaupt nicht davon gesprochen, wie es bei XUL ist, sondern lediglich gesagt, dass das jetzt nicht komplizierter ist. Und die von mir genannten fünf Minuten haben sich ganz klar auf die Zeit bezogen, die es benötigt, um die Voraussetzungen zu schaffen. Die Installation von Python und das Herunterladen des SDKs sollte nicht viel länger als fünf Minuten dauern, selbst wenn es zehn Minuten sind. Um den Übersetzungsaufwand ging es überhaupt nicht, auch nicht darum, die existierenden Texte auszulagern, denn das ist für den Vergleich SDK - XUL unerheblich, weil es in beiden Fällen genauso lange dauert.

Zitat von milupo

Das interessiert alles nicht. Die Voraussetzungen zu schaffen ist nicht die Sache der Übersetzer, sondern der Erweiterungsautoren und von Mozilla. Hätte, könnte, sollte, wollte .. das bringt doch alles nichts.

Ich wiederhole mich: Nein. Die Voraussetzungen zu schaffen ist dann Aufgabe von Mozilla, wenn Mozilla Übersetzungen anbietet, sonst nicht. Mozilla muss ganz sicher keine Voraussetzungen für etwas schaffen, was überhaupt nicht Teil des Produkts ist.