Firefox 3.0 (Nightly; "Gran Paradiso") in deutsch

Hallo TheRave, hallo alle,

ich war wohl etwas vorschnell mit meinem Optimismus, dass die Phase der Spielereien wieder erträgliche Ausmaße angenommen hätte.

Die jetzt zelebrierte Unart ist es, eine "2" hinter jedes Schlüsselwort zu setzen. Das kam zwar schon immer mal mit vor, ist aber am vergangenen Wochenende extrem geworden.

Beispiel:
(locale/browser/safebrowsing/blockedSite.properties)

Aus

phishing.title
phishing.shortDesc
phishing.longDesc

wurde

phishing.title2
phishing.shortDesc2
phishing.longDesc2

Auch in vielen anderen Dateien tauchen jetzt plötzlich jede Menge Zweien auf. Die Erklärung, dass das etwas mit Firefox 2 zu tun haben könnte, glaube ich nicht ganz, denn diese Phishing-Geschichte gibt es in Firefox 2 noch gar nicht.

Also bleibt doch wohl nur Langeweile bei den Entwicklern als wahrscheinlichste Erklärung :roll:

Grüße
DAC324
P.S.: Es gibt mal wieder ein Update von mir.

Allerdings hat es einen Nachteil: Damit das Update für den Firefox selbst funktioniert, muss man in about:config den Wert für general.useragent.locale auf en-US setzen. Anschließend sofort den Menüpunkt Hilfe, Firefox aktualisieren aufrufen.

Sollte es kein Update geben, muss general.useragent.locale wieder zurückgesetzt werden.

Wenn das Update herunter geladen wird, kann man die Einstellung ebenfalls wieder zurück setzen.

Auch meine Erweiterung setzt sie entsprechend bei jedem Update wieder auf de-DE zurück.

Zitat von Minotauros

Was war denn an den Antworten im MozillaZine Forum falsch, auch beim Safebrowsing wurden Strings geändert.
http://forums.mozillazine.org/viewtopic.php?p=3227740#3227740
http://forums.mozillazine.org/viewtopic.php?p=3227909#3227909

Hallo Minotauros,

das ist mir schon klar, dass Strings geändert wurden. Aber wenn man sich die Änderungen selbst so ansieht, wird man den Eindruck nicht los, dass da jemand ziemlich gelangweilt ist.
Erklärung: An Strings, about:robots und der Hilfedatei bastelt man eigentlich nur dann herum, wenn es nichts mehr zu implementieren gibt oder man aus irgend einem Grund nicht weiter kommt.
Schließlich sieht es nicht appetitlich aus, wenn man sich statt dessen den ganzen Tag in der Nase bohrt

Wie gesagt, mir war's beim Programmieren immer am wichtigsten, das Pflichtenheft umzusetzen und wenigstens die nervigsten Bugs zu entfernen. Wie da die Variablen heißen, ist eher zweitrangig. Deshalb hat man eigentlich auch keine Zeit, sich um so was zu kümmern, wenn noch andere Aufgaben anliegen.
Code-beautifying macht man ganz am Schluss...

Aber wie gesagt, ist nur meine persönliche Meinung,

DAC324

Zitat von Minotauros

Hallo DAC324,
Das Umbenennen der Keys hilft den Lokalisierern die Stellen zu finden, die eine Änderung der Übersetzung erfordern.

Hallo Minotauros,

klingt ja ganz gut, ich gebe aber zu bedenken, dass die Original-Strings ja in der Mehrzahl der Fälle die gleichen bleiben.
Die Dateien des Sprachpaketes sind nach dem Muster

Variablenbezeichner=Inhalt (zu übersetzender Text)

aufgebaut.

Nur die Variablenbezeichner/Schlüsselworte (z.B. Entities) werden geändert. Die zu übersetzenden Texte bleiben in der Mehrzahl der Fälle gleich, auch wenn in dem von Dir verlinkten Text steht

Zitat

If you change the semantics of a localized string, change the key.

Wie gesagt, der "localized string" bleibt in der überwiegenden Zahl der Fälle exakt derselbe, nur der Name des Keys wird geändert - und genau das entzieht sich leider meinem Verständnis.

Mit anderen Worten gefragt: Warum ändert man den Keynamen, wenn der zugehörige String der gleiche bleibt?

Ich bin gespannt auf alle hilfreichen Hinweise

Beste Grüße,
DAC324

Zitat von Minotauros

Bei den drei Beispielen vom Safebrowsing wurde der Text inhaltlich geändert, in welchen Fällen war das denn nicht so?

Ich hab das Ganze jetzt gerade nicht hier am Rechner, aber spontan fällt mir als Beispiel der Copyright-Text in browser/aboutDialog.dtd ein. Hier wurde von "CopyrightText" auf "CopyrightInfo" abgeändert, der Text blieb jedoch derselbe.

Beste Grüße

DAC324

Zitat von TheRave

Hm. Ich gehe eigentlich sowieso immer im Safemode zum updaten, ist da jetzt was anders?

Ja, ich weiß nicht genau, woran's liegt, aber scheinbar werden mitunter die Einstellungen unter

app.update.url
app.update.url.override

ignoriert.

Wie komme ich darauf? In app.update.url gibt es einen Teil /%LOCALE%/. Dieser wird beim Aufruf des Updates durch die Spracheinstellung vom Firefox (general.useragent.locale) ersetzt, es wird bei der englischen Version z.B. /en-US/ daraus.

Nun gibt es natürlich für nicht-englische Versionen keine Nightly Updates.

Bisher konnte man sich behelfen, indem man von Hand den Teil /%LOCALE%/ durch /en-US/ ersetzte. Dann konnte man auch mit der deutschen Version des Firefox die Updates herunterladen, ohne vorher die Sprache verstellen zu müssen.

Seit einiger Zeit funktioniert das aber nicht mehr, es kommt trotzdem beim Versuch eines Updates die Fehlermeldung

AUS: Update-Datei nicht gefunden (404)

Erst wenn man general.useragent.locale umstellt, funktioniert das Update auch wieder.

Beim Safe-Mode passiert das übrigens automatisch

Grüße,
DAC324

Zitat von Minotauros

Code

(From update of attachment 299250 [details])
> <!ENTITY copyrightText          "©1998-2008 Contributors. All Rights Reserved. Firefox and the 
>                                  Firefox logos are trademarks of the Mozilla Foundation.  All rights 
>-                                 reserved. Some trademark rights used under license from The 
>-                                 Charlton Company.">
>+                                 reserved.">


You need to rev this entity if you expect localizers to fix this for their
locales.

Oha, schlechtes Beispiel - da muss ich wohl was übersehen haben. Leider hab ich mir nicht alles aufgeschrieben...hab mich immer nur geärgert.

Mir ist es auch schon passiert, dass mir Dateien als aktualisiert angezeigt wurden (ich vergleiche immer das Dateidatum zwischen den Original- und den übersetzten Dateien - geht mitunter schneller als die Bonsai-Abfrage) und schlußendlich war aber gar nichts geändert worden.

Grüße
DAC324

Zitat von Minotauros

Deshalb würde ich gerne konkrete Beispiele dafür sehen.

Ich bitte um etwas Geduld Es wird sich sicherlich bald wieder etwas finden.

Zitat

Vielleicht liegt das Problem bei deiner Vergleichsmethode.

Das kann ich natürlich nicht ausschließen.
Die Bonsai-Abfrage hat freilich neben der Tatsache, dass sie zeitaufwendiger sein kann, den Nachteil, dass man eigentlich keinen Hourly-Build überspringen dürfte, um auch wirklich alle Änderungen mitzubekommen. Das wäre aber ein Fulltime-Job - leider habe ich schon einen solchen, den ich auch besser beibehalten sollte, weil er bezahlt wird

Wenn man nur mit den Nightly Builds arbeitet (und dabei womöglich aus Zeitmangel noch welche überspringt) übersieht man bei der zu dem jeweils letzten Build gehörenden Bonsai-Abfrage die Checkins, die Eingang in die dazwischen liegenden Builds gefunden haben.

Deshalb bleibt zunächst nur der Vergleich der Zeitstempel zwischen übersetzten und Original-Dateien übrig. Damit bekommt man immerhin alle Dateien, die seit der letzten Änderung an der Übersetzung geändert wurden.

Allerdings ist es für jemanden, der diese ganze Geschichte in seiner Freizeit nach Feierabend macht, immer noch extrem zeitaufwendig, für jede der geänderten Dateien eine Bonsai-Abfrage durchzuführen.

Denn momentan befindet man sich (leider immer noch) in einer Phase sehr umfangreicher Änderungen. Während z.B. Ende 2007 teilweise wochenlang keine der Sprachdateien angefasst wurde, sind es jetzt von einem Nightly Build zum nächsten manchmal über 20 Stück (das war z.B. der Fall, als man in den Menüeinträgen "..." durch "…" ersetzte (drei einzelne Punkte durch ein in UTF-8 vorhandenes einzelnes Zeichen, das die drei Punkte zusammenfasst).

Besser wäre ein Tool, das die Keys zwischen Übersetzung und Original vergleicht und automatisch alle geänderten Keys anzeigt. Wenn man das manuell macht, übersieht man immer einige der geänderten Keys und muss mehrfach testen. Das ist sehr mühsam.

Leider hab ich so ein Tool noch nicht gefunden...werde es wohl mal selber programmieren müssen :shock:

Beste Grüße

DAC324

Zitat von Minotauros

Ehrlich gesagt halte ich die Vorstellung, dass Mozilla-Entwickler aus Langeweile oder um sich vor Arbeit zu drücken willkürlich Entities ändern für völlig abwegig. Jede Änderung braucht mindestens eine Überprüfung (review) und auch die Lokalisierungsteams würden aufschreien wenn sie sinnlose Arbeit aufgehalst bekämen. Deshalb würde ich gerne konkrete Beispiele dafür sehen. Vielleicht liegt das Problem bei deiner Vergleichsmethode.

Hallo Minotauros,

wie schon vermutet: Ich brauchte nicht lange zu warten.

Hier ein Beispiel:

browser/browser.dtd

Version 1.101:
<!ENTITY showAllBookmarksCmd.label2 "Organize Bookmarks">

Version 1.102:
<!ENTITY showAllBookmarksCmd2.label "Organize Bookmarks">

Selbe Datei, etwas weiter unten:

Version 1.101:
<!ENTITY showAllHistoryCmd.label2 "Show All History">

Version 1.102:
<!ENTITY showAllHistoryCmd2.label "Show All History">

Keine Änderung des Textes, aber der Entity...:D Alles klar???

Grüße,
DAC324

Zitat von Minotauros

Ich weiß nicht welche Werkzeuge die offiziellen Übersetzer benutzen, bei den von dir genannten Beispielen habe ich in der mxr/ lxr nach der Datei gesucht, dort kann man z.B. Versionen vergleichen oder das CVS Log ansehen. Wenn man den Grund für eine Änderung nicht kennt, kann man daraus nicht schließen, dass es auch keinen gibt.

mxr/lxr?

Ich habe "nur" über Bonsai die Diffs verglichen. Sorry, aber zu weitergehenden Nachforschungen fehlen mir wirklich Zeit und Lust. Wie gesagt, ich beschäftige mich in meiner Freizeit mit dieser Geschichte und habe deshalb nicht den ganzen Tag Zeit, die Innereien des Mozilla-Entwicklungssystems zu erforschen.

Abgesehen davon sagt mir

Zitat von cvs-log

1.102; Bug 421609: avoid non-common entity names, a=mconnor

nicht wirklich was. Wenn Du das verstehst - Glückwunsch.

Anscheinend taucht das Problem, dass man bei den Änderungen im Eifer des Gefechts die Namenskonventionen vergisst, immer wieder mal auf. Das, was ich hier erwähnte, trat nicht zum ersten Mal auf.

Aber egal, was mich momentan wesentlich mehr ärgert, ist der Umstand, dass die Einstellungen app.update.url bzw. app.update.url.override (in about:config) zumindest teilweise ignoriert werden.

In früheren Versionen reichte es, den Teil /%LOCALE%/ in den Strings durch /en-US/ zu ersetzen. Dann konnte man auch mit installiertem Sprachpaket Updates für die Nightly Builds herunterladen.

Jetzt wird offenbar zusätzlich noch general.useragent.locale abgefragt - warum, erschließt sich mir leider nicht, denn normalerweise ersetzt Firefox beim Aufruf der Update-URL den /%LOCALE%/ - Teil bereits durch diese Einstellung.
Die zusätzliche Abfrage ist also redundant und damit überflüssig.

Grüße,
DAC324

Zitat von Minotauros

Zu dem Updateproblem mit Sprachpaketen:
Ich habe zum Testen ein älteres Nightly entpackt, ein deutsches Sprachpaket von hier genommen und general.useragent.locale auf de gestellt. Damit konnte ich problemlos updaten, soweit ich weiß ist es seit Bug 334136 beim Updaten egal welchen Wert general.useragent.locale in der prefs.js im Profilordner hat.

Wir reden jetzt beide vom Update des Firefox selbst, nicht von Add-Ons, Sprachpaketen oder dergleichen?
Wenn ich bei mir auf "Hilfe, Firefox aktualisieren" gehe, bekomme ich immer die Fehlermeldung: AUS: Update-Datei nicht gefunden (404).
Erst wenn ich in about:config die Einstellung general.useragent.locale auf en-US setze, funktioniert es mit dem Update des Firefox selbst.
In beiden Fällen wird der gleiche URL aufgerufen (überprüft mit LiveHTTPHeaders)...

ratlos,
DAC324