Hallo Endor
in Form enter https://addons.mozilla.org/de/firefox/sea…latform=windows ist nicht mehr kompatibel mit FF 55.0.1. 64Bit
Kannst Du eventuell hier auch was schrauben?
Och schade, was mach ich nun 
aber trotzdem vielen Dank für's testen.
Du hättest sowieso unverschämtes Glück, wenn Endor wirklich noch eine funktionierende Version hat. Informenter wird seit 2013 nicht mehr weiterentwickelt.
Du hättest sowieso unverschämtes Glück, wenn Endor wirklich noch eine funktionierende Version hat. Informenter wird seit 2013 nicht mehr weiterentwickelt.
Warum soll ich nicht auch mal Glück haben? Im default Profil 55.0.1 läuft es nämlich, nur im neuen Test Profil natürlich nicht mehr.
Wegen diesem Addon mach ich aber kein Fass auf!
Hallo,
was passiert eigentlich mit der Liste? Wird diese aktualisiert, verkleinert, gestrichen, was auch immer, da ja vieles nicht mehr ab Firefox 57 funktioniert?
Vielleicht machen wir ja noch was mit Webextensions.
Ja, das wäre gut. :klasse:
Hallo,was passiert eigentlich mit der Liste? Wird diese aktualisiert, verkleinert, gestrichen, was auch immer, da ja vieles nicht mehr ab Firefox 57 funktioniert?
Die muss erst einmal vollständig gestrichen werden, es birngt nichts die Einträge alter Erweiterungen mitzuschleppen. Sie ist sowieso nur aus zwei Gründen da: einmal um eine (vorläufige) Übersetzung zu ergänzen und andererseits aufgegebene Erweiterungen anzubieten, die doch noch irgendwie zum Laufen gebracht wurden. Der letztere Fall wird erst einmal nicht mehr vorkommen, denn alle Erweiterungen werden neu sein, denn eine neue WebExtension sollte laufen und ist dann auch nicht aufgegeben.
Bei den Übersetzungen hängt es davon ab, inwieweit diese aus den Versionen alten Typs übernommen werden können bzw. wie die Zusammenarbeit mit dem Add-on-Entwickler ist. Bei Oleksander z. B. kannst du hinschreiben und er baut das sofort in seine Erweiterungen ein. Wenn du aber mal bei ihm registriert bist, schreibt er dich dann auch wieder an, wenn es etwas Neues zu übersetzen gibt. Erst dann ist es nötig, dass wir die Übersetzung hier anbieten.
Nachtrag: Die Erweiterungen in unserer Liste wurden meistens von den Benutzern angefragt. Das spielt also auch eine Rolle. Keine Nachfrage, kein Listeneintrag.
Dann warten wir einfach mal ab. 
Hallo,
ich habe per Zufall eine nette Erweiterung entdeckt. Muss man nicht übersetzen, könnte man aber machen. :lol:
Ich schaue sie mir mal an.
Irgendwie ist das wieder Scheiße mit Web Paint. Ein Teil der Strings sind in einer ellenlangen javaScript-Datei und ein paar andere in einer CSS-Datei. Du musst dir wieder aus Tausenden von Zeilen paar Strings zusammensuchen. Normalerweise sollte die Erweiterung mehrere Locales unterstützen, so wie Sörens Erweiterungen Bookmarks Organizer und New Tab Override. Der Entwickler macht es sich etwas einfach. Englisch und sonst nichts, Ich blicke da nicht durch. Ich will XUL zurück! Mag Sören sagen, was er will. Aber da hatte ich als Nichtentwickler und einfacher Übersetzer noch Einfluss.
Ich will XUL zurück! Mag Sören sagen, was er will. Aber da hatte ich als Nichtentwickler und einfacher Übersetzer noch Einfluss.
Ich verstehe den Punkt nicht. Das hat doch nichts mit XUL zu tun. Egal, ob alte XUL-Erweiterung, SDK-Erweiterung oder WebExtensions, in jeder Architektur (!) gab es Übersetzungs-Dateien. Das Format hat sich geändert, die Sache an sich aber überhaupt nicht. Früher wie heute konnte man ganz genauso seine Erweiterung entweder übersetzbar machen oder nicht, indem man einfach alle Texte direkt in den Quellcode schreibt. Da gibt es keinen Unterschied zu früher. Der Entwickler muss sich halt die zusätzliche Arbeit machen und das macht nicht jeder. Wie gesagt, das ist vollkommen Architektur-unabhängig.
PS: HTML-Dateien in WebExtensions zu übersetzen, ist übrigens gar nicht so einfach, das zur Verteidigung mancher. Ich hab mir meine eigene kleine Klasse dafür geschrieben. Die darf gerne jeder, der auch Erweiterungen schreibt, verwenden:
https://github.com/cadeyrn/newtab…/src/js/i18n.js
Einfach in die HTML-Dateien einbinden und es werden automatisch alle Zeichenketten der Strukur __MSG_variablenname__ übersetzt.
Ich konnte aber in XUL-Dateien meine eigenen Entities erfinden, falls die Strings hardcodiert waren und konnte dann sogar mehrere Locales hinzufügen, mit den entsprechenden .dtd- und .properties-Dateien. Je mehr JavaScript dazu kam, um so weniger Einfluss hatte der Übersetzer und bei Web Paint hast du eine ellenlange JavaScript-Datei (inject.js) mit Text in einer einzigen Zeile.
Du siehst selbst, dass du sogar noch etwas dazu erfinden musst, eine eigene JavaScript-Datei, um die Übersetzung von HTML-Dateien zu ermöglichen. Ich habe mir die angesehen, und wenn ich ja doch noch herumexperimentiere, wollte ich die einbauen - sofern du das gestattest. Da sieht man den Bezug zwischen i18n.js und den String-Namen in der messages.json (Präfix _MSG_). Aber das ist ein besonderer Service von dir, mit dem man sonst wohl nicht rechnen kann. Ich verstehe auch halbwegs, was auf dieser MDN-Seite zu lesen ist:
https://developer.mozilla.org/en-US/Add-ons/…nationalization
Wenn ich das richtig verstehe, brauchst du bestimmte Funktionen, um die Strings herauszuziehen, auf den JavaScript-Code habe ich aber keinen Einfluss. AMO sollte dafür sorgen, dass keine Erweiterung die Prüfung besteht, die kein Minimalgerüst für die Lokalisierung hat, sprich einen Ordner _locales mit dem Unterordner en-US und der entsprechenden messages.json darin sowie natürlich den erforderlichen JavaScript-Code. Der Entwickler von Web Paint scheint Chinese zu sein. Um so unverständlicher ist es für mich, dass ein Entwickler, dessen Muttersprache nicht Englisch ist, keine Lokalisierungsmöglichkeit anbietet. Es gibt Tausende von Sprachen auf dieser Welt und es gibt immer noch Leute, die glauben, andere Sprachen als Englisch ignorieren zu können.
Auch bei SDK-Erweiterungen oder WebExtensions kann man zusätzliche Übersetzungen hinzufügen oder hardgecodete Strings ersetzen. JavaScript hat damit nichts zu tun, denn via JavaScript greifst du ja auch nur auf die vorhandenen Übersetzungen zu. Und JavaScript ist ja auch nicht mit neueren Architekturen neu dazu gekommen. Meine Legacy-Erweiterung "FM Scene" (habe ich heute gemeinsam mit zwei anderen meiner Erweiterungen von AMO gelöscht) war auch eine XUL-Erweiterung und die hat sogar zwei verschiedene Sprachdateien pro Sprache gebraucht, eine für XUL, eine andere in einem anderen Format für JavaScript, also du siehst, das gab es damals schon, da kann ich eine eigene Erweiterung als Beispiel nennen. 
Dass für die Übersetzung von HTML-Dateien bei WebExtensions derzeit keine fertige Lösung existiert, ist unglücklich, aber es ist nicht so, als wäre das nur bei XUL-Erweiterungen komfortabel gewesen. Im SDK war das auch ziemlich einfach. Es war auf jeden Fall eine schöne Übung für mich, mit XPath arbeite ich sonst nicht.
Ich widerspreche aber der Forderung, dass eine Lokalisierbarkeit erzwungen werden sollte. Vor allem ist das technisch gar nicht möglich, dass man das automatisiert, weswegen es notwendig wäre, dass Menschen die Architektur jeder Erweiterung verstehen und genauestens überprüfen, dass jeder Text, der sichtbar ist, in einer Sprachvariable ist und korrekt darauf zugegriffen wird. Das heißt dann auch, dass die Warteschlange für Add-on-Prüfungen ein paar Wochen statt Tage dauern wird. Und ich bezweifle, dass das die freiwilligen Prüfer lange mitmachen.
Darüber hinaus kann man das auch einfach nicht pauschal fordern. Es gibt nun einmal Add-ons, da hat es überhaupt keinen Sinn, sie mehrsprachig anzubieten. Nicht jedes Add-on hat ein internationales Publikum.
