1300406 - Seamonkey 2.48 German localization

Status: RESOLVED WONTFIX

(Mozilla Localizations :: de / German, defect)

Description

[Frank-Rainer Grahl (:frg)]

Attachment: 248-suite-de-wip.patch

Only wip patches for now.

Comment 1

[Frank-Rainer Grahl (:frg)]

Attachment: 248-editor-de-wip.patch

Composer wip patch

Comment 2

[Frank-Rainer Grahl (:frg)]

habe gestern festgestellt das die Umlaute in den WIP Patches kaputt sind weil ich die über das Clipboard kopiert hatte. Ich stelle nächste Woche aktualisierte Patches ein.

Comment 3

[Frank-Rainer Grahl (:frg)]

Attachment: seamonkey-248-de-wip.patch

Aktueller Patch. 

Sollen die zwei PNG Dateien rein? Dann wäre de was Images angeht komplett. Alle anderen sind im de Tree schon vorhanden.

Comment 4

[Frank-Rainer Grahl (:frg)]

Für die Validierungshilfe existiert auch noch Bug 1228920. Die Teile könnte man dahin verschieben oder den zu machen.

Comment 5

[Robert Kaiser]

(In reply to Frank-Rainer Grahl from comment #2)
> habe gestern festgestellt das die Umlaute in den WIP Patches kaputt sind
> weil ich die über das Clipboard kopiert hatte. Ich stelle nächste Woche
> aktualisierte Patches ein.

Die Dinge außerhalb der Hilfe sollte ich mittlerweile schon erledigt haben, denke ich.

(In reply to Frank-Rainer Grahl from comment #3)
> Sollen die zwei PNG Dateien rein? Dann wäre de was Images angeht komplett.
> Alle anderen sind im de Tree schon vorhanden.

Wenn sie in den deutschen Dateien referenziert sind, dann schon - ansonsten bringt's nichts.

Comment 6

[Frank-Rainer Grahl (:frg)]

Attachment: seamonkey-248-de-wip.patch

>>
Die Dinge außerhalb der Hilfe sollte ich mittlerweile schon erledigt haben, denke ich.
<<

In dataman.properties fehlt noch die neue Variable für die Speicherung von Passwörtern. 
consoleoverlay.dtd gibt es nicht mehr. 
Ditto einige Hilfedateien im helpviewer Verzeichnis nach der helpoverlay Aufräumaktion.

Das eine png wird verwendet. Ohne l10n-merge bricht der Build ab. Mit l10n-merge wird wohl die US Version rangezogen aber ich habe es immer noch nicht installiert. Ohne sieht man schneller was kaputt ist :)

Comment 7

[Robert Kaiser]

(In reply to Frank-Rainer Grahl from comment #6)
> Das eine png wird verwendet. Ohne l10n-merge bricht der Build ab. Mit
> l10n-merge wird wohl die US Version rangezogen aber ich habe es immer noch
> nicht installiert. Ohne sieht man schneller was kaputt ist :)

Build ohne l10n-merge sind nicht unterstützt. Ich bin sogar dafür, dass Builds mit anderen Locales als en-US desupported werden und L10n nur mehr über Repacks unterstützt wird. Wir haben zu viele verschiedene Pfade und das Build-System für L10n ist so schon kompliziert genug. Dass Repacks derzeit für SeaMonkey kaputt sind, ist allerdings ein echtes Problem.

Comment 8

[Frank-Rainer Grahl (:frg)]

>>
Build ohne l10n-merge sind nicht unterstützt. Ich bin sogar dafür, dass Builds mit anderen Locales als en-US desupported werden und L10n nur mehr über Repacks unterstützt wird. Wir haben zu viele verschiedene Pfade und das Build-System für L10n ist so schon kompliziert genug. 
<<

Amen bzw. +1. Mal gucken was l20n bringt. 

l10n-merge ist nur urgkk und ohne kriegt man in lokalen Builds sofort mit wenn etwas fehlt. 

Was das fehlende png angeht: So finde ich es auch inkonsistent. Entweder man wirft alle raus die identisch mit denen in en-US sind oder man packt Sie alle rein. So sieht es immer nach einem Fehler aus.

Comment 9

[Robert Kaiser]

(In reply to Frank-Rainer Grahl from comment #8)
> Was das fehlende png angeht: So finde ich es auch inkonsistent. Entweder man
> wirft alle raus die identisch mit denen in en-US sind oder man packt Sie
> alle rein. So sieht es immer nach einem Fehler aus.

Unter help/ ist es unerheblich, ob etwas in en-US existiert oder nicht, da geht es nur darum, was in den deutschen Hilfe-Dateien verwendet wird oder nicht. Ein Werkzeug wie l10n-merge kann das natürlich schlecht abbilden. Aber IMHO sollte die Hilfe von vorherein nicht im Code sein und auch nicht Dinge wie RDF/XML verwenden. Aber das ist nicht meine Entscheidung.

Comment 10

[Frank-Rainer Grahl (:frg)]

>> da geht es nur darum, was in den deutschen Hilfe-Dateien verwendet wird oder nicht.

Jetzt wo du es sagst. Da fehlt der ganze Absatz zu "balloon help" in der deutschen Hilfe und dort ist in en-US mail_newmail_ballon.png drinnen:

https://dxr.mozilla.org/comm-central/source/suite/locales/en-US/chrome/common/help/mailnews_preferences.xhtml

Ich guck mal ob schon ein bug dafür existiert.

Comment 11

[Robert Kaiser]

(In reply to Frank-Rainer Grahl from comment #10)
> >> da geht es nur darum, was in den deutschen Hilfe-Dateien verwendet wird oder nicht.
> 
> Jetzt wo du es sagst. Da fehlt der ganze Absatz zu "balloon help" in der
> deutschen Hilfe und dort ist in en-US mail_newmail_ballon.png drinnen:
> 
> https://dxr.mozilla.org/comm-central/source/suite/locales/en-US/chrome/
> common/help/mailnews_preferences.xhtml
> 
> Ich guck mal ob schon ein bug dafür existiert.

Ja, wenn das hinzugefügt wird, sollte die Grafik auch dazu kommen, das ist sinnvoll. :)

Comment 12

[Frank-Rainer Grahl (:frg)]

Attachment: 1300406-suite-de-aurora.patch

Mit dem Patch sollte 2.48 erstmal weitgehend erledigt sein.

Löschung der überflüssigen und nicht benutzten Overlays + ehemaligen Toolkit Hilfe- und Consoledateien. 
css Variable die umbenannt wurde.
Fehlende Daten Manager Variable für Passwörter.

Comment 13

[Robert Kaiser]

Comment on attachment 8805961 [details] [diff] [review]
1300406-suite-de-aurora.patch

Review of attachment 8805961 [details] [diff] [review]:
-----------------------------------------------------------------

Um die Entfernung hab ich mich kaum gekümmert, die sind auch nur notwendig, um "sauber" zu sein, ist wohl eine gute Idee. Und die CSS-Änderung ist natürlich auch OK. Aber bitte das mit dem "fehlenden" String überprüfen.

::: suite/chrome/common/dataman/dataman.properties
@@ +27,1 @@
>  perm.offline-app.label=Offline-Web-Anwendungen

Laut https://l10n.mozilla.org/teams/de haben wir keinen fehlenden String auf Aurora, ist der sicher nicht drin?

Comment 14

[Frank-Rainer Grahl (:frg)]

> perm.login-saving.label=Passwörter speichern

Der wird nicht erkannt weil er dynamisch eingebunden wird. Ich hatte die en-US Version selbst in Bug 1294997 in den Data Manager eingepflegt. Fehlt er ist es nicht ganz so schlimm weil dann die Bezeichung der Permission aka. login-saving selbst angezeigt wird aber für die Neuanlage und Anzeige ist es schöner.

Siehe suite\common\dataman\dataman.js Zeile 1443:

> typeDesc = gDataman.bundle.getString("perm." + permType + ".label");

Comment 15

[Robert Kaiser]

(In reply to Frank-Rainer Grahl from comment #14)
> Der wird nicht erkannt weil er dynamisch eingebunden wird.

Wenn er in en-US nicht drin ist, ist es semantisch flasch, ihn in irgendeine Übersetzung aufzunehmen, daher bin ich für 2.48 dagegen.

Für Nightly nehme ich gerne einen Patch mit den anderen Änderungen an, aber ich pflege ungern Dinge erst auf späteren branches ein, wenn es nicht wirklich nötig ist (und da obselete files/strings kein Problem für die Builds usw. darstellen, bin ich nicht dafür, sie irgendwo anders als Nightly einzupflegen).

Comment 16

[Robert Kaiser]

Comment on attachment 8805961 [details] [diff] [review]
1300406-suite-de-aurora.patch

Review of attachment 8805961 [details] [diff] [review]:
-----------------------------------------------------------------

r- nur weil nichts im Patch drin ist, was ich außerhalb von Nightly als etwas sehe, das einzupflegen ist.
Einen entsprechenden Patch für Nightly nehme ich wie gesagt gern an.

Comment 17

[Frank-Rainer Grahl (:frg)]

Attachment: 1300406-suite-de-beta.patch

Anbei der geänderte Patch.

perm.login-saving.label wird benutzt und ist in en-US. Der Merge ist nur zu doof und findet es wohl nicht weil es dynamisch im Code zusammengebaut wird:

https://dxr.mozilla.org/comm-beta/source/suite/locales/en-US/chrome/common/dataman/dataman.properties

Siehe Kommentar 14 hier.

Patch enthält nur noch:
css Variable die umbenannt wurde.
Fehlende Daten Manager Variable für Passwörter.

Comment 18

[Robert Kaiser]

(In reply to Frank-Rainer Grahl from comment #17)
> perm.login-saving.label wird benutzt und ist in en-US. Der Merge ist nur zu
> doof und findet es wohl nicht weil es dynamisch im Code zusammengebaut wird

Wenn es merge/compare-locales nicht finden, dann muss ein grober Fehler im Code sein, und ich unterstütze keine Code-Ausbesserungen über einen Umweg von L10n.

Comment 19

[Frank-Rainer Grahl (:frg)]

>>
Wenn es merge/compare-locales nicht finden, dann muss ein grober Fehler im Code sein, und ich unterstütze keine Code-Ausbesserungen über einen Umweg von L10n.
<<

Gut mir wurscht. Meine private Version hat die Übersetzung drinnen und dann wird den Benutzern halt nur login-saving in der deutschen Version angezeigt. l10n-merge erkennt es nicht als benutzt weil die Variable dynamisch zusammengebaut wird. In der en-US Version vorhandene aber nicht offensichtlich benutze Variablen werden dann wohl nicht als fehlend angezeigt. Der urspüngliche Code im Data Manager stammt von dir :)

Comment 20

[Robert Kaiser]

(In reply to Frank-Rainer Grahl from comment #19)
> l10n-merge erkennt es nicht als benutzt weil die Variable dynamisch
> zusammengebaut wird.

Das muss l10n-merghe bzw. compare-locales komplett egal sein, es kümmert sich normal nur darum, was in den en-US-L10n-Dateien vorhanden ist, und daher kommt mir das ganze sehr spanisch vor.

Comment 21

[Frank-Rainer Grahl (:frg)]

Attachment: Clipboard.png

Anbei ein Screenshot. Ich kann eine deutsche Version installieren aber das ist es von der Zeit her eigentlich nicht wert für eine einzelne Variable. Ich hatte es damals auprobbiert als ich den Code ergänzt hatte. In der deutschen Version würde ohne das Label nur der interne Name login-saving angezeigt werden. Ebenso bei Neuanlage in der Combobox. Warum das l10n-merge nicht mitbekommt -> keine Ahnung.

Comment 22

[Frank-Rainer Grahl (:frg)]

Ist Save Passwords in der englischen Version.

Comment 23

[Robert Kaiser]

Das glaube ich alles, mein "problem" ist rein mit dem, was compare-locales bzw. l10n-merge sieht/macht.

Comment 24

[Frank-Rainer Grahl (:frg)]

Ich denke der Bug könnte zu.

Comment 25

[Robert Kaiser]

Ja, leider haben wir nicht alles geschafft, aber ab 2.49 sollte es besser sein ;-)