Beiträge von Sören Hentzschel

Hallo,

Updates erhältst du bei jedem Smartphone über den Provider, das ist bei Mozilla-Smartphones nicht anders. Ausnahme ist Geeksphone, weil das nicht über Provider vertrieben wird, da erhältst du Updates über den Hersteller. Mozilla selbst verteilt keine Updates auf Geräte. Aber natürlich kann man sich selbst den Code der aktuellsten Version herunterladen, kompilieren und auf sein Smartphone spielen. Der Vorgang dauert dann halt ein paar Stündchen.

Geeksphone hat eine Download-Seite, auch mit Beta-Versionen und Nightly-Builds (also jeden Tag neu) zum selbst Raufspielen auf dein Gerät, falls du nicht auf die offiziellen Updates "over-the-air" warten und nicht selbst kompilieren möchtest:

http://downloads.geeksphone.com/

Aber gerade wenn das System bereits kompromittiert ist, dann möchte man das doch wissen, um entsprechend darauf reagieren zu können, oder nicht? Und was, wenn die Apps nicht aus dem Firefox Marketplace heruntergeladen worden sind? Mozilla unterstützt ausdrücklich die Verwendung auch anderer App Stores. Und selbst im Firefox Marketplace kann mal was durchgehen, bei Mozilla arbeiten auch nur Menschen. Und nicht zuletzt darf man nicht vergessen, dass viele Inhalte aus dem Web kommen. Das kann Mozilla gar nicht kontrollieren, was sich da nachträglich nach der Überprüfung verändert.

Das liegt aber dann tatsächlich überhaupt nicht am SDK, sondern ausschließlich an den Erweiterungen selbst. Es gibt auch Unmengen Nicht-SDK-Erweiterungen, welche nicht übersetzt sind. Der Unterschied zwischen SDK und Nicht-SDK bezüglich Übersetzung ist praktisch nicht vorhanden. Der größte Unterschied neben dem Unterschied im Format (kein Unterschied im Aufwand) ist, dass man beim SDK in jedem Fall nur mit einer Art von Files arbeiten muss, bei Nicht-SDK Erweiterungen teilweise mit zwei verschiedenen Arten von Files. Beispiel gefällig? Ich habe auch schon eine Erweiterung entwickelt, welche nicht auf dem SDK basiert und Gebrauch von beiden Arten von Files für die Übersetzung machen muss:

https://addons.mozilla.org/de/firefox/fil…/de/fmscene.dtd
https://addons.mozilla.org/de/firefox/fil…cene.properties

Und ist eine Nicht-SDK Erweiterung nicht übersetzt, dann musst du da ganz genauso suchen. Es bringt also absolut nichts, da die Schuld auf das SDK zu schieben. Wenn überhaupt kann sich die Kritik gegen den Entwickler der entsprechenden Erweiterung richten, welcher auf Mehrsprachigkeit verzichtet. Aber dafür habe ich sogar Verständnis - denn die meisten Entwickler können halt nicht mehrere Sprachen so gut, dass eine Übersetzung sinnvoll wäre und dann braucht man externe Leute, die das übersetzen. Die Erweiterung in meinem Beispiel habe ich auch extern übersetzen lassen.

Add-ons nur von AMO installierbar zu machen, hat Mozilla meines Wissens nicht vor. Es gab einen Vorschlag zur Registrierung von Add-ons, der so aber wohl nicht durchgeführt werden wird, die Installation aus anderen Quellen aber auch weiter erlaubt.

Zitat von ElseAT

Fx ("Fx"? :-?? sacht man das jezz so? So unter uns Fachleuten? muahaha)

Fx ist die offizielle Abkürzung für Firefox. Das stand früher in den Häufig gestellten Fragen als Bestandteil der Release Notes zu neuen Firefox-Versionen.

Zitat von milupo

Gott sei Dank, der idiotische Add-on-Builder wird bald eingestampft. Jetzt warte ich noch darauf, dass auch das Add-on-SDK, der Albtraum aller Add-on-Übersetzer, eingestampft wird.

Darauf kannst du lange warten, das wird nich passieren, zum Glück nicht. Das SDK macht es so extrem einfach, Add-ons zu erstellen... Es ist eher das Gegenteil der Fall: XUL gilt es heute zu vermeiden, was charakteristisch für die allermeisten Nicht-SDK Add-ons ist. Wieso das SDK ein Albraum für Übersetzer sein soll, das ist mir auch ein Rätsel. Übersetzen ist nicht schwieriger als bei Nicht-SDK-Erweiterungen... Ob du nun ein .properties- oder .json-File (SDK) oder ein .dtd- und/oder .properties-File (Nicht-SDK - dort muss man teilweise mit zwei verschiedenen Arten von Dateien arbeiten, weil .dtd für XUL und .properties für JavaScript benutzt wird) übersetzt, das ist doch egal.

Ich weiß auch nicht, was daran gut sein soll, dass der Add-on Builder eingestellt wird. Das macht es für Anfänger schwieriger, Add-ons zu erstellen... Und ich habs gerne zum Prototyping benutzt...

Das ist seit Version 23 der Fall. <blink /> war noch nie Bestandteil des HTML-Standards und Firefox war der letzte Browser, der dieses Element überhaupt noch unterstützt hat, alle anderen Browser unterstützen es schon länger nicht mehr. Für Gestaltung gibt es CSS, das hat in HTML nichts verloren, genauer text-decoration: blink;

Aber ganz ehrlich, tu den Besuchern deiner Webseite einen Gefallen und verzichte darauf. Sonst rufen die 1990er an und verlangen ihren Blink-Effekt zurück... Blinkende Texte auf Webseiten sind sehr verpönt...

Hallo,

in deinen Screenshots ist klar zu erkennen, dass sich der Ordner plugins bei dir nicht im Ordner browser befindet, wie er sollte.

Hallo,

ausdrucken, ausfüllen, Scheck beilegen, per Post in die USA schicken:
https://static.mozilla.com/foundation/doc…donate_form.pdf

Mein Beitrag hat zwar nichts mit der Übersetzung und damit nicht direkt mit dem Thema zu tun, aber danke für den Hinweis auf Version 1.0.5, damit läuft Lightbeam wieder im Nightly!

Das ist extrem unwahrscheinlich, dass das Absicht ist, wir reden hier immerhin von den Nightly Builds, dort genauso wie in den Aurora-Versionen soll es die Modern UI-Oberfläche geben, denn diese wird aktiv entwickelt und benötigt Tester. Absichtlich deaktiviert ist sie in den Beta- und Release-Versionen.

Der für die Modern UI-Oberfläche von Windows 8 angepasste Firefox. Wenn du kein Windows 8 hast, dann hast du das auch nicht.

Kann ich bestätigen! Ich finde allerdings keinen bestehenden Bug...

Wenn das nicht nur für diese Domain gelten soll, dann spricht nichts dagegen. Wobei ich nicht glaube, dass es noch eine zweite Webseite gibt, welche -moz-user-select auf none gesetzt und dem body-Element außerdem die Klasse "nc" gegeben hat, das wäre schon ein merkwürdiger Zufall. Vielleicht sollte man dann auch einfach nur body und nicht body.nc als Selektor verwenden, denn ob das body-Element noch eine Klasse hat, ist ja eigentlich egal, das Element ist auch so eindeutig.

So steht das ja im CSS der Seite und darum funktioniert das Markieren nicht. Der Wert von -moz-user-select muss auto anstatt none sein.

Na das Übliche: userContent.css oder Stylish.

@-moz-document url(http://www.example.com) {
   /* CSS Code */
}

Im CSS-Code der Seite steht folgendes:

body.nc {
    -moz-user-select: none;
}

Was auch immer der Betreiber der Seite sich davon verspricht... Hast also vollkommen richtig vermutet, BeeHaa. Setze den Wert auf auto und es funktioniert.

Dazu kann ich leider nichts sagen.

Hallo,

das nächste Mal bitte als Link, das macht es übersichtlicher und man kann sich durchklicken.

Das hier ist der Link zu deinem Bericht:
https://crash-stats.mozilla.com/report/index/7…da-0c79c2131227

Tritt das Problem denn auch in der finalen Version 26 von Firefox auf? Hast du es mal im Abgesicherten Modus (Hilfe → Mit deaktivierten Add-ons neu starten) versucht?

Hallo,

Zitat von bigpen

Seit längerer Zeit habe ich Lightbeam 1.0.2 installiert. Damit kann ich sehen wohin und ob überhaupt, besuchte Seiten Drittanbieter-Cookies senden. Hat die Erweiterung noch andere Möglichkeiten, die ich noch nicht entdeckt habe?

Du kannst mit Lightbeam nicht nur sehen, sondern auch blockieren (im Unterschied zur alten Collusion-Erweiterung). Außerdem kannst du die gesammelten Daten an Mozilla übertragen, um Mozillas Forschung auf dem Gebiet des Trackings und der Privatsphäre zu unterstützen. Diese Daten fließen auch in eine öffentliche Datenbank; Mozilla plant eine Webseite, auf der dann die Visualisierungen anderer Nutzer (natürlich ohne dass ein Bezug zu dir als Person hergestellt werden kann) angesehen werden können.