Closed Bug 385325 Opened 18 years ago Closed 17 years ago

Update editor L10n after consistency check with suite L10n

Categories

(Mozilla Localizations :: de / German, defect)

Product:
Mozilla Localizations
Component:
de / German
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla2.0

People

(Reporter: kairo, Assigned: kairo)

Details

Attachments

(1 file, 1 obsolete file)

Patch for syncing of editor part of German L10n, v2
75.63 KB, patch
Thunderbird_Mail_DE
: review+
Details | Diff | Splinter Review
After syncing the security/ part of German L10n between my internal suite version and CVS in bug 383713, I'm working on syncing the editor/ui part in the same way. This will probably get another quite huge patch, but for review by Alex instead of Abdulkadir :)
This patch syncs up German L10n CVS with my local MT glossary and current trunk.
Attachment #269217 - Flags: review?(AlexIhrig)
-<!ENTITY compositionToolbarCmd.label "Composition"> +<!ENTITY compositionToolbarCmd.label "Bearbeiten-Symbolleiste"> In Thunderbird wird prinzipiell der Teil "-Symbolleiste" nicht genannt, da das Wort Symbolleiste bereits der Titel des Submenus ist. "Bearbeiten" wäre aber vermutlich (habe keinen trunkbuild...) okay. -<!ENTITY formattingToolbarCmd.label "Formatierung"> +<!ENTITY formattingToolbarCmd.label "Format-Symbolleiste"> siehe oben -<!ENTITY editmodeToolbarCmd.label "Editiermodus"> +<!ENTITY editmodeToolbarCmd.label "Bearbeitungsmodus-Symbolleiste"> siehe oben / "Bearbeitungsmodus" wäre okay -<!ENTITY taskbarCmd.label "Status"> +<!ENTITY taskbarCmd.label "Statusleiste"> bitte ohne "leiste", da überall im Programm analog "Status" verwendet wird. -ServerNotAvailable=Der Server ist nicht verfügbar. Kontrollieren Sie Ihre Verbindung und versuchen Sie es später nochmals. -Offline=Sie sind derzeit offline. Klicken Sie auf das Symbol in der Nähe des linken unteren Randes eines Fensters, um online zu gehen. +ServerNotAvailable=Der Server ist nicht verfügbar. Überprüfen Sie Ihre Verbindung und versuchen Sie es später nochmals. +Offline=Sie sind derzeit offline. Klicken Sie auf das Symbol nahe der unteren rechten Ecke eines Fensters, um online zu gehen. In Thunderbird ist das Symbol LINKS unten in der Statusleiste! Ich sehe hier ein Problem, das mich schon in Enigmails Übersetzung immer nervt: die unterschiedlichen Themes -CancelPublishMessage=Abbrechen während dem Publizieren kann in unvollständig übertragenen Dateien resultieren. Möchten Sie fortsetzen oder abbrechen? +CancelPublishMessage=Abbrechen während dem Publizieren kann in unvollständig übertragenen Dateien resultieren. Wollen Sie fortfahren oder abbrechen? möchten/wollen -NoNamedAnchorsOrHeadings=(Keine Anker oder Überschriften auf dieser Seite) +NoNamedAnchorsOrHeadings=(Keine benannten Anker oder Überschriften auf dieser Seite) 2. Variante ist okay (es gab aber einen Grund dafür, dass ich das "benannter" weggenommen habe irgendwann - nur leider fällt mir der Grund gerade nicht ein - eventuell die Größe des Dialogs? -NamedAnchor=Anker +NamedAnchor=Benannter Anker siehe oben -Label=Etikett +Label=Beschriftung ist okay - bringt mich endlich weg von der Verwirrung hier rund um Tags/Etiketten (da dieses label gar nichts damit zu tun hat...) -DeleteTableMsg=Vermindern der Zeilen- bzw. Spaltenanzahl löscht Tabellenzellen samt Inhalt. Möchten Sie das wirklich machen? +DeleteTableMsg=Vermindern der Zeilen- bzw. Spaltenanzahl löscht Tabellenzellen samt Inhalt. Wollen Sie das wirklich machen? möchten/wollen -DictDownldConfirmMsg=%brand% wird das aktuelle Fenster schließen und Sie zu einer Seiten weiterleiten, von der Sie eine Rechtschreibprüfung herunterladen können. +DictDownldConfirmMsg=%brand% wird das aktuelle Fenster schließen und Sie zu einer Site weiterleiten, von der Sie eine Rechtschreibprüfung herunterladen können. 1. Variante hat einen Typo oder es müsste "Website" heißen. -<!ENTITY saveAsChangeEncodingCmd.label "Zeichenkodierung speichern und anwenden"> +<!ENTITY saveAsChangeEncodingCmd.label "Zeichensatz speichern und ändern"> Hier wird ja wohl nicht ein Zeichensatz (z.B. "Arial") gespeichert, oder doch? Es wird wohl eher die Zeichenkodierung gespeichert! -<!ENTITY pasteHTML.accesskey "h"> +<!ENTITY pasteHTML.accesskey "H"> <!ENTITY pasteTextCmd.label "Text"> -<!ENTITY pasteText.accesskey "t"> +<!ENTITY pasteText.accesskey "T"> geht in Ordnung -<!ENTITY editpastelink.accesskey "l"> +<!ENTITY editpastelink.accesskey "L"> geht in Ordnung -<!ENTITY editfindprev.accesskey "v"> +<!ENTITY editfindprev.accesskey "V"> geht in Ordnung -<!ENTITY insertlink.accesskey "l"> +<!ENTITY insertlink.accesskey "L"> geht in Ordnung -<!ENTITY insertAnchorCmd.label "Anker..."> +<!ENTITY insertAnchorCmd.label "Benannter Anker..."> siehe weiter oben -<!ENTITY insertHTMLCmd.accesskey "h"> +<!ENTITY insertHTMLCmd.accesskey "H"> geht in Ordnung -<!ENTITY insertLabelCmd.label "Etikett definieren"> +<!ENTITY insertLabelCmd.label "Beschriftung definieren"> okay -<!ENTITY spellCheckNoSuggestions.label "Keine Vorschläge gefunden"> -<!ENTITY spellCheckIgnoreWord.label "Ignoriere dieses Wort"> +<!ENTITY spellCheckNoSuggestions.label "(Keine Vorschläge gefunden)"> +<!ENTITY spellCheckIgnoreWord.label "Wort ignorieren"> okay / "Dieses Wort ignorieren" -<!ENTITY spellCheckAddToDictionary.label "Zu Benutzerwörterbuch hinzufügen"> -<!ENTITY spellCheckAddToDictionary.accesskey "n"> +<!ENTITY spellCheckAddToDictionary.label "Zu Wörterbuch hinzufügen"> +<!ENTITY spellCheckAddToDictionary.accesskey "Z"> Benutzerwörterbuch ist richtiger/eindeutiger, denn es wird nicht z.B. ins deutsche Wörterbuch hinzugefügt! Accesskey scheint okay zu sein -<!ENTITY createlink.accesskey "k"> +<!ENTITY createlink.accesskey "L"> okay -<!ENTITY copy.accesskey "k"> +<!ENTITY copy.accesskey "K"> okay -<!ENTITY fontfixedwidth.accesskey "F"> +<!ENTITY fontfixedwidth.accesskey "B"> okay -<!ENTITY localfontmenu.accesskey "f"> +<!ENTITY localfontmenu.accesskey "k"> wo ist das label dazu? -<!ENTITY increasefontsize.accesskey "g"> +<!ENTITY increasefontsize.accesskey "G"> okay <!-- Font Style SubMenu --> <!ENTITY fontStyleMenu.label "Schriftschnitt"> -<!ENTITY formatstylemenu.accesskey "s"> +<!ENTITY formatstylemenu.accesskey "S"> <!ENTITY styleBoldCmd.label "Fett"> -<!ENTITY stylebold.accesskey "f"> +<!ENTITY stylebold.accesskey "F"> <!ENTITY stylebold.keybinding "b"> <!ENTITY styleItalicCmd.label "Kursiv"> <!ENTITY styleitalic.accesskey "K"> <!ENTITY styleitalic.keybinding "i"> <!ENTITY styleUnderlineCmd.label "Unterstrichen"> -<!ENTITY styleunderline.accesskey "u"> +<!ENTITY styleunderline.accesskey "U"> <!ENTITY styleunderline.keybinding "u"> <!ENTITY styleStrikeThruCmd.label "Durchgestrichen"> -<!ENTITY stylestrikethru.accesskey "d"> +<!ENTITY stylestrikethru.accesskey "D"> <!ENTITY styleSuperscriptCmd.label "Hochgestellt"> <!ENTITY stylesuperscript.accesskey "H"> <!ENTITY styleSubscriptCmd.label "Tiefgestellt"> <!ENTITY stylesubscript.accesskey "T"> <!ENTITY styleNonbreakingCmd.label "Ohne Umbruch"> -<!ENTITY stylenonbreaking.accesskey "o"> +<!ENTITY stylenonbreaking.accesskey "O"> <!ENTITY styleEm.label "Hervorgehoben"> -<!ENTITY styleEm.accesskey "e"> +<!ENTITY styleEm.accesskey "v"> <!ENTITY styleStrong.label "Stark hervorgehoben"> -<!ENTITY styleStrong.accesskey "s"> +<!ENTITY styleStrong.accesskey "S"> <!ENTITY styleCite.label "Zitat"> -<!ENTITY styleCite.accesskey "z"> +<!ENTITY styleCite.accesskey "Z"> <!ENTITY styleAbbr.label "Abkürzung"> -<!ENTITY styleAbbr.accesskey "a"> +<!ENTITY styleAbbr.accesskey "A"> <!ENTITY styleAcronym.label "Akronym"> -<!ENTITY styleAcronym.accesskey "r"> +<!ENTITY styleAcronym.accesskey "y"> <!ENTITY styleCode.label "Code"> <!ENTITY styleCode.accesskey "C"> <!ENTITY styleSamp.label "Beispielausgabe"> -<!ENTITY styleSamp.accesskey "B"> +<!ENTITY styleSamp.accesskey "e"> <!ENTITY styleVar.label "Variable"> -<!ENTITY styleVar.accesskey "v"> +<!ENTITY styleVar.accesskey "V"> okay -<!ENTITY formatRemoveNamedAnchors.label "Anker entfernen"> +<!ENTITY formatRemoveNamedAnchors.label "Benannte Anker entfernen"> siehe weiter oben -<!ENTITY paragraphparagraph.accesskey "a"> +<!ENTITY paragraphparagraph.accesskey "A"> okay -<!ENTITY formatlistmenu.accesskey "l"> +<!ENTITY formatlistmenu.accesskey "L"> -<!ENTITY listterm.accesskey "t"> +<!ENTITY listterm.accesskey "T"> -<!ENTITY listdefinition.accesskey "d"> +<!ENTITY listdefinition.accesskey "D"> -<!ENTITY listprops.accesskey "l"> +<!ENTITY listprops.accesskey "L"> -<!ENTITY bodytext.accesskey "t"> +<!ENTITY bodytext.accesskey "T"> okay -<!ENTITY AddressAbbr.label "Addr."> +<!ENTITY AddressAbbr.label "Adr."> okay (Du hast korrekt nur ein "d") -<!ENTITY formatalignmenu.accesskey "a"> +<!ENTITY formatalignmenu.accesskey "A"> okay -<!ENTITY layerSendToBack.tooltip "In Hintergrund stellen"> -<!ENTITY layerBringToFront.tooltip "In Vordergrund stellen"> +<!ENTITY layerSendToBack.tooltip "In den Hintergrund stellen"> +<!ENTITY layerBringToFront.tooltip "In den Vordergrund bringen"> okay (evtl. Platzproblem bei Thunderbird?) -<!ENTITY grid.label "Positioning grid"> -<!ENTITY grid.accesskey "t"> +<!ENTITY grid.label "Positionierungsgitter"> +<!ENTITY grid.accesskey "P"> okay -<!ENTITY tableallcells.accesskey "a"> +<!ENTITY tableallcells.accesskey "A"> okay -<!ENTITY converttotable.accesskey "r"> +<!ENTITY converttotable.accesskey "w"> okay -<!ENTITY toolsmenu.accesskey "l"> -<!ENTITY toolbrowser.accesskey "b"> -<!ENTITY toolplaineditor.accesskey "p"> -<!ENTITY toolsetfocus.accesskey "f"> +<!ENTITY toolsmenu.accesskey "t"> +<!ENTITY toolbrowser.accesskey "B"> +<!ENTITY toolplaineditor.accesskey "T"> +<!ENTITY toolsetfocus.accesskey "F"> wo sind die labels? -<!ENTITY testSelectionCmd.label "Test Auswahl"> -<!ENTITY testTableLayoutCmd.label "Test Tabellen Layout"> -<!ENTITY testDocumentCmd.label "Test Dokument"> +<!ENTITY testSelectionCmd.label "Test-Auswahl"> +<!ENTITY testTableLayoutCmd.label "Test-Tabellenlayout"> +<!ENTITY testDocumentCmd.label "Testdokument"> Test-Auswahl, Test-Tabellenlayout und Test-Dokument würde ich machen. Das wäre konsequent bei den Wortketten und hilft beim Lesen durch den Bindestrich, der das "Test-" klar zeigt. -<!ENTITY compositionToolbar.tooltip "Funktionen-Symbolleiste"> +<!ENTITY compositionToolbar.tooltip "Bearbeiten-Symbolleiste"> Die Toolbar soll in Thunderbird IMMER in JEDEM Fenster als "Funktionen-Symbolleiste" bezeichnet sein. Daher tue ich mich schwer mit Bearbeiten-Symbolleiste. -<!ENTITY publishToolbarCmd.tooltip "Datei auf ferne Adresse laden"> +<!ENTITY publishToolbarCmd.tooltip "Datei auf externe Adresse hochladen"> okay -<!ENTITY textColorCaption.label "Text-Farbe"> +<!ENTITY textColorCaption.label "Textfarbe"> okay -<!ENTITY throbber.tooltip "&vendorShortName; Homepage aufrufen"> +<!ENTITY throbber.tooltip "&vendorShortName;-Homepage aufrufen"> Der Throbber hat in Firefox/Thunderbird meines Wissens keinen Link mehr. Daher wird auch der Tooltip nicht mehr angezeigt. Somit ist mir relativ egal was hier steht. -<!ENTITY NormalMode.accesskey "n"> -<!ENTITY NormalMode.tooltip "Tabellenränder und Anker anzeigen"> +<!ENTITY NormalMode.accesskey "N"> +<!ENTITY NormalMode.tooltip "Tabellenränder und benannte Anker anzeigen"> Wieso hier ein großes "N"? Es gibt nur kleine "n" im label. "benannte" siehe oben -<!ENTITY HTMLSourceMode.accesskey "h"> +<!ENTITY HTMLSourceMode.accesskey "H"> okay -<!ENTITY editorCheck.accesskey "c"> +<!ENTITY editorCheck.accesskey "C"> okay --- weiteres im nächsten comment
-<!ENTITY smiley4Cmd.tooltip "Ein Gesicht mit der Zunge heraus einfügen"> +<!ENTITY smiley4Cmd.tooltip "Ein Gesicht mit herausgestreckter Zunge einfügen"> okay -<!ENTITY SmileButton.tooltip "Einen Smiley einfügen"> +<!ENTITY SmileButton.tooltip "Ein Smiley-Gesicht einfügen"> Ich finde "Smiley" besser, da es universeller ist und man damit beim Chatten teilweise auch Grafiken meint, die kein Gesicht darstellen. -<!ENTITY crInPCreatesNewP.label "Zeilenschaltung innerhalb eines Absatzes erzeugt neuen Absatz"> +<!ENTITY crInPCreatesNewP.label "Enter innerhalb eines Absatzes erzeugt immer einen neuen Absatz"> Enter ist meines Wissens auf dem Mac nicht gebräuchlich. Ich denke "Zeilenschaltung" ist besser. -<!ENTITY activeLinkText.label "Aktiver Link"> +<!ENTITY activeLinkText.label "Aktiver Link-Text"> <!ENTITY activeLinkText.accesskey "t"> -<!ENTITY visitedLinkText.label "Besuchter Link"> +<!ENTITY visitedLinkText.label "Besuchter Link-Text"> okay -<!ENTITY preview.label "Durchsuchen"> +<!ENTITY preview.label "Vorschau"> habe den Kontext nicht, aber scheint okay -<!ENTITY anchor.label "Ziel"> +<!ENTITY anchor.label "Anker"> dito -<!ENTITY tabJSE.label "JavaScript Ereignisse"> +<!ENTITY tabJSE.label "JavaScript-Ereignisse"> okay -<!ENTITY instructions2.label "Wählen Sie das Zeichen, welches in der Auswahl die Spalten trennt:"> +<!ENTITY instructions2.label "Wählen Sie das Zeichen, das die Auswahl in Spalten trennt:"> scheint okay <!ENTITY spaceRadio.label "Abstand"> wo ich es gerade sehe: das müsste besser "Leerzeichen" heißen. "Abstand" ist Unsinn, da das Schriftzeichen "Leerzeichen"/"Space" gemeint ist. -<!ENTITY otherRadio.label "anderes Zeichen:"> -<!ENTITY deleteCharCheck.label "Lösche Trennzeichen"> +<!ENTITY otherRadio.label "Anderes Zeichen:"> +<!ENTITY deleteCharCheck.label "Trennzeichen löschen"> -<!ENTITY collapseSpaces.tooltip "Konvertiere mehrfache Leerzeichen zu einem Trennzeichen"> +<!ENTITY collapseSpaces.tooltip "Zusammenhängende Leerzeichen in ein Trennzeichen umwandeln"> okay -<!ENTITY succeeded.label "Erflogreich"> +<!ENTITY succeeded.label "Erfolgreich"> okay -<!ENTITY windowTitle.label "Eigenschaften des Ankers"> +<!ENTITY windowTitle.label "Eigenschaften des benannten Ankers"> siehe oben -<!ENTITY nameInput.tooltip "Geben Sie einen eindeutigen Namen für diesen Anker an"> +<!ENTITY nameInput.tooltip "Geben Sie einen eindeutigen Namen für diesen benannten Anker (Ziel) an"> siehe oben -<!ENTITY AccessKey.label "Zugriffstaste"> +<!ENTITY AccessKey.label "Zugriffstaste:"> wenn der Doppelpunkt hier hingehört, dann okay (habe den Dialog nicht vor Augen) -<!ENTITY windowTitle.label "Felderbereich-Eigenschaften"> +<!ENTITY windowTitle.label "Felderbereichs-Eigenschaften"> Mit dem "s" tue ich mich immer wieder schwer bei Wortketten. Abdulkadir??? -<!ENTITY LegendAlign.accesskey "A"> +<!ENTITY LegendAlign.accesskey "a"> okay -<!ENTITY FormName.accesskey "N"> +<!ENTITY FormName.accesskey "n"> okay -<!ENTITY windowTitle.label "Horizontal-Linien Einstellung"> +<!ENTITY windowTitle.label "Eigenschaften der horizontalen Linie"> okay -<!ENTITY dimensionsBox.label "Größe"> +<!ENTITY dimensionsBox.label "Dimensionen"> Ich denke "Größe" ist besser. "Dimensionen" ist zu wörtlich übersetzt, auch wenn es ebenfalls korrekt ist. -<!ENTITY centerRadio.accessKey "C"> +<!ENTITY centerRadio.accessKey "Z"> okay -<!ENTITY saveSettings.label "Standard verwenden"> -<!ENTITY saveSettings.accessKey "D"> -<!ENTITY saveSettings.tooltip "Einstellungen speichern, um sie für neue horizontale Linien zu nutzen"> +<!ENTITY saveSettings.label "Als Standard verwenden"> +<!ENTITY saveSettings.accessKey "S"> +<!ENTITY saveSettings.tooltip "Diese Einstellungen speichern, um sie beim Einfügen neuer horizontaler Linien zu verwenden"> okay -<!ENTITY clear.accesskey "d"> +<!ENTITY clear.accesskey "L"> <!ENTITY selectall.accesskey "u"> -<!ENTITY close.accesskey "l"> -<!ENTITY cut.accesskey "x"> -<!ENTITY copy.accesskey "c"> -<!ENTITY paste.accesskey "v"> -<!ENTITY props.accesskey "p"> -<!ENTITY tbar.accesskey "t"> \ No newline at end of file +<!ENTITY close.accesskey "c"> +<!ENTITY cut.accesskey "A"> +<!ENTITY copy.accesskey "K"> +<!ENTITY paste.accesskey "E"> +<!ENTITY props.accesskey "E"> +<!ENTITY tbar.accesskey "y"> wo sind die labels?
-<!ENTITY title.tooltip "Das HTML-Attribut &quot;title&quot;, das als Tooltip angezeigt wird"> +<!ENTITY title.tooltip "Das HTML-Attribut 'title', das als Tooltip angezeigt wird"> okay
-<!ENTITY editImageMapButton.tooltip "Anklickbare Hotspots (-->Links) für dieses Bild erstellen"> +<!ENTITY editImageMapButton.tooltip "Anklickbare Hotspots (Links) für dieses Bild erstellen"> okay -<!ENTITY TextLength.accesskey "L"> +<!ENTITY TextLength.accesskey "l"> okay -<!ENTITY Accept.accesskey "A"> +<!ENTITY Accept.accesskey "a"> okay -<!ENTITY borderEditField.label "Rand"> +<!ENTITY borderEditField.label "Rand:"> okay -<!ENTITY LabelFor.label "Steuerelement:"> +<!ENTITY LabelFor.label "Für Steuerelement:"> Mir fehlt der Kontext -<!ENTITY location.label "Adresse"> +<!ENTITY location.label "Adresse:"> -<!ENTITY authorInput.label "Autor"> +<!ENTITY authorInput.label "Autor:"> -<!ENTITY descriptionInput.label "Beschreibung"> +<!ENTITY descriptionInput.label "Beschreibung:"> okay -<!ENTITY DictionaryList.label "Liste der Wörter:"> +<!ENTITY DictionaryList.label "Wörter im Wörterbuch:"> Ersteres würde ich bevorzugen. Mir gefällt die Doppelung von "Wörter" nicht. -<!ENTITY siteList.accesskey "e"> -<!ENTITY siteList.tooltip "Wählen Sie die Site, auf die Sie publizieren möchten"> +<!ENTITY siteList.accesskey "S"> +<!ENTITY siteList.tooltip "Wählen Sie die Site, auf die Sie publizieren wollen"> -<!ENTITY docDirList.tooltip "Choose or enter the name of the remote subdirectory for this page"> +<!ENTITY docDirList.tooltip "Wählen Sie oder geben Sie den Namen des externen Unterverzeichnisses für diese Seite ein"> Ich würde "Wählen Sie den Namen des externen Unterverzeichnisses dieser Seite bzw. geben Sie den Namen ein" schreiben. -<!ENTITY publishImgCheckbox.accesskey "o"> +<!ENTITY publishImgCheckbox.accesskey "k"> okay -<!ENTITY sameLocationRadio.accesskey "U"> +<!ENTITY sameLocationRadio.accesskey "G"> okay -<!ENTITY useSubdirRadio.accesskey "d"> -<!ENTITY useSubdirRadio.tooltip "Publish files to the selected remote subdirectory"> -<!ENTITY otherDirList.tooltip "Choose or enter name of remote subdirectory where files will be published"> +<!ENTITY useSubdirRadio.accesskey "D"> +<!ENTITY useSubdirRadio.tooltip "Dateien im gewhlten externen Unterverzeichnis publizieren"> +<!ENTITY otherDirList.tooltip "Wählen Sie oder geben Sie den Namen des externen Unterverzeichnisses ein, in dem die Dateien publiziert werden sollen"> 1. Typo in Deiner Variante: es fehlt ein ä in gewählten 2. bei otherDirList.tooltip: siehe oben -<!ENTITY pageTitle.accesskey "T"> +<!ENTITY pageTitle.accesskey "t"> okay -<!ENTITY filename.accesskey "F"> +<!ENTITY filename.accesskey "e"> okay -<!ENTITY setDefaultButton.label "Als Standard setzen"> -<!ENTITY setDefaultButton.accesskey "D"> +<!ENTITY setDefaultButton.label "Als Standard festlegen"> +<!ENTITY setDefaultButton.accesskey "A"> okay -<!ENTITY removeButton.accesskey "R"> +<!ENTITY removeButton.accesskey "r"> okay -<!ENTITY siteName.accesskey "e"> +<!ENTITY siteName.accesskey "S"> okay -<!ENTITY siteUrl.label "Publizierungs-URL (z.B.: 'ftp://ftp.meinprovider.at/meinbenutzername'):"> -<!ENTITY siteUrl.accesskey "a"> +<!ENTITY siteUrl.label "Publizierungs-Adresse (z.B.: 'ftp://ftp.meinprovider.at/meinbenutzername'):"> +<!ENTITY siteUrl.accesskey "P"> okay -<!ENTITY username.accesskey "U"> +<!ENTITY username.accesskey "B"> okay -<!ENTITY savePassword.accesskey "S"> +<!ENTITY savePassword.accesskey "o"> okay -<!ENTITY succeeded.label "erfolgreich"> -<!ENTITY failed.label "fehlgeschlagen"> +<!ENTITY succeeded.label "Erfolgreich"> +<!ENTITY failed.label "Fehlgeschlagen"> vermutlich okay -<!ENTITY findField.label "Suchen nach:"> +<!ENTITY findField.label "Text suchen:"> okay -<!ENTITY caseSensitiveCheckbox.label "Groß-/Kleinschreibung beachten"> +<!ENTITY caseSensitiveCheckbox.label "Groß-/Kleinschreibung berücksichtigen"> Erstere Variante finde ich besser und sie ist kürzer, was z.B. in der Findbar ganz entscheidend ist, da diese teilweise schon auf meinem 19-Zöller zu breicht wird. Auch wenn wir hier nicht (?) in der Findbar sind, so würde ich prinzipiell von "beachten" sprechen wollen. -<!ENTITY documentCharsetDesc.label "Den Zeichensatz unter dem Sie speichern möchten, angeben:"> +<!ENTITY documentCharsetDesc.label "Wählen Sie den Zeichensatz, in dem Sie ein Dokument speichern wollen:"> 1. möchten/wollen 2. sonst finde ich Deine Formulierung besser; und ja hier ist es der Zeichnsatz ;-) -<!ENTITY SelectName.accesskey "N"> +<!ENTITY SelectName.accesskey "n"> okay -<!ENTITY OptionSelected.label "Anfänglich ausgewählt"> +<!ENTITY OptionSelected.label "Anfangs ausgewählt"> mhhh, scheint beides okay zu sein -<!ENTITY cellSelectPrevious.label "Vorherige"> +<!ENTITY cellSelectPrevious.label "Vorhergehende"> Meins ist kürzer, Deins klingt besser... Abdulkadir??? -<!ENTITY cellAlignBottom.label "Unter"> +<!ENTITY cellAlignBottom.label "Unten"> Deins ist korrekt, okay -editor.throbber.url=http://www.mozilla.org/projects/seamonkey/ +editor.throbber.url=http://www.seamonkey.at/ Throbber für Thunderbird uninterssant - also Deine Variante ----- puhh, das war's für heute Nacht erstmal
(In reply to comment #3) > -<!ENTITY SmileButton.tooltip "Einen Smiley einfügen"> > +<!ENTITY SmileButton.tooltip "Ein Smiley-Gesicht einfügen"> > > Ich finde "Smiley" besser, da es universeller ist und man damit beim Chatten > teilweise auch Grafiken meint, die kein Gesicht darstellen. Aye. "Smiley" entspricht auch der mir bekannten Umgangssprache.
(In reply to comment #5) > -<!ENTITY cellSelectPrevious.label "Vorherige"> > +<!ENTITY cellSelectPrevious.label "Vorhergehende"> > > Meins ist kürzer, Deins klingt besser... Abdulkadir??? Vorherige klingt meiner Meinung nach besser.
(In reply to comment #2) > -<!ENTITY compositionToolbarCmd.label "Composition"> > +<!ENTITY compositionToolbarCmd.label "Bearbeiten-Symbolleiste"> > > In Thunderbird wird prinzipiell der Teil "-Symbolleiste" nicht genannt, da das > Wort Symbolleiste bereits der Titel des Submenus ist. Dann haben wir hier ein grobes Problem. Im SeaMonkey heißt das Menü überall "Anzeigen/Verstecken >" - da ist es ohne "Symbolleiste" völlig sinnlos. > -<!ENTITY taskbarCmd.label "Status"> > +<!ENTITY taskbarCmd.label "Statusleiste"> > > bitte ohne "leiste", da überall im Programm analog "Status" verwendet wird. Und in SeaMonkey überall "Statusleiste"... Ein "Status" kann doch überall angezeigt werden, was ich verwirrend finden würde... > -ServerNotAvailable=Der Server ist nicht verfügbar. Kontrollieren Sie Ihre > Verbindung und versuchen Sie es später nochmals. > -Offline=Sie sind derzeit offline. Klicken Sie auf das Symbol in der Nähe des > linken unteren Randes eines Fensters, um online zu gehen. > +ServerNotAvailable=Der Server ist nicht verfügbar. Überprüfen Sie Ihre > Verbindung und versuchen Sie es später nochmals. > +Offline=Sie sind derzeit offline. Klicken Sie auf das Symbol nahe der unteren > rechten Ecke eines Fensters, um online zu gehen. > > In Thunderbird ist das Symbol LINKS unten in der Statusleiste! Sicher, auch im Trunk? Ich erinnere mich, dass das auf Grund eines Bugs der Fall war, obwohl es rechts hätte sein sollen. Der Bug ist IIRC aber mittlerweile gefixt und es sollte jetzt korrekt rechts unten sein. > -NoNamedAnchorsOrHeadings=(Keine Anker oder Überschriften auf dieser Seite) > +NoNamedAnchorsOrHeadings=(Keine benannten Anker oder Überschriften auf dieser > Seite) > > 2. Variante ist okay (es gab aber einen Grund dafür, dass ich das "benannter" > weggenommen habe irgendwann - nur leider fällt mir der Grund gerade nicht ein > - eventuell die Größe des Dialogs? Ich hab überlegt, ob ich's ändern soll oder nicht- aber schließlich ist ein <a> ohne name-Attribut auch ein Anker, aber ein unbenannter, daher hab ich das zusammenstimmend mit dem en-US eingefügt. > -Label=Etikett > +Label=Beschriftung > > ist okay - bringt mich endlich weg von der Verwirrung hier rund um > Tags/Etiketten (da dieses label gar nichts damit zu tun hat...) Eben :) Irgendwo in security/ gibt's "label" tatsächlich als Etikett eines Geräts, aber sonst ist "Etikett" etwas komisch ;-) > -DictDownldConfirmMsg=%brand% wird das aktuelle Fenster schließen und Sie zu > einer Seiten weiterleiten, von der Sie eine Rechtschreibprüfung herunterladen > können. > +DictDownldConfirmMsg=%brand% wird das aktuelle Fenster schließen und Sie zu > einer Site weiterleiten, von der Sie eine Rechtschreibprüfung herunterladen > können. > > 1. Variante hat einen Typo oder es müsste "Website" heißen. Also wieder ein Fall, der mit bug 385452 zusammenhängt ;-) > -<!ENTITY saveAsChangeEncodingCmd.label "Zeichenkodierung speichern und > anwenden"> > +<!ENTITY saveAsChangeEncodingCmd.label "Zeichensatz speichern und ändern"> > > Hier wird ja wohl nicht ein Zeichensatz (z.B. "Arial") gespeichert, oder doch? > Es wird wohl eher die Zeichenkodierung gespeichert! Das heißt "Zeichensatz" - ich hatte da einige Diskussionen um das Thema, bis ich meine Übersetzung einheitlich auf "Zeichensatz" umgestellt habe. "Arial" ist eine Schriftart, ein Zeichensatz ist die im Deutschen übliche Bezeichnung für ein "Character Encoding", vgl. http://de.wikipedia.org/wiki/Zeichensatz#Zeichens.C3.A4tze_f.C3.BCr_Computersysteme > -<!ENTITY spellCheckAddToDictionary.label "Zu Benutzerwörterbuch hinzufügen"> > -<!ENTITY spellCheckAddToDictionary.accesskey "n"> > +<!ENTITY spellCheckAddToDictionary.label "Zu Wörterbuch hinzufügen"> > +<!ENTITY spellCheckAddToDictionary.accesskey "Z"> > > Benutzerwörterbuch ist richtiger/eindeutiger, denn es wird nicht z.B. ins > deutsche Wörterbuch hinzugefügt! Dann müssen wir das auch im en-US ändern. Ich bin überhaupt kein Freund davon, in der Übersetzung selbständig Bedeutungen zu variieren, wenn der Bug im en-US auch existiert. Er gehört zumindest dort gemeldet, bevor wir ihn einseitig in de verbessern. > -<!ENTITY localfontmenu.accesskey "f"> > +<!ENTITY localfontmenu.accesskey "k"> > > wo ist das label dazu? localfontfaceMenu.label > -<!ENTITY toolsmenu.accesskey "l"> > -<!ENTITY toolbrowser.accesskey "b"> > -<!ENTITY toolplaineditor.accesskey "p"> > -<!ENTITY toolsetfocus.accesskey "f"> > +<!ENTITY toolsmenu.accesskey "t"> > +<!ENTITY toolbrowser.accesskey "B"> > +<!ENTITY toolplaineditor.accesskey "T"> > +<!ENTITY toolsetfocus.accesskey "F"> > > wo sind die labels? Das hab ich mich auch gefragt :( Sollte ich noch genauer nachforschen... > -<!ENTITY compositionToolbar.tooltip "Funktionen-Symbolleiste"> > +<!ENTITY compositionToolbar.tooltip "Bearbeiten-Symbolleiste"> > > Die Toolbar soll in Thunderbird IMMER in JEDEM Fenster als > "Funktionen-Symbolleiste" bezeichnet sein. Daher tue ich mich schwer mit > Bearbeiten-Symbolleiste. Wer hat diesen Standard erfunden? "Funktionen-Symbolleiste" wirkt für mich sehr sinnlos als Wort, sagt gar nichts aus. Eine Symbolleiste hat doch immer irgendwelche Funktionen, ganz gleich, ob sie zum Bearbeiten oder für sonstwas sind. Das Tooltip sollte für mich einen Namen haben, der mit dem Anzeigen/Verstecken-Menü zustmmenstimmt, sodass man den Zusammenhang findet. > -<!ENTITY NormalMode.accesskey "n"> > -<!ENTITY NormalMode.tooltip "Tabellenränder und Anker anzeigen"> > +<!ENTITY NormalMode.accesskey "N"> > +<!ENTITY NormalMode.tooltip "Tabellenränder und benannte Anker anzeigen"> > > Wieso hier ein großes "N"? Es gibt nur kleine "n" im label. "benannte" siehe > oben Ähm, der .accesskey ist doch nicht für das .tooltip, sondern für das .label, und das heißt "Normaler Editier-Modus". Wobei mir gerade auffällt, dass das "Bearbeitungsmodus" auch besser wäre ;-) (In reply to comment #3) > -<!ENTITY crInPCreatesNewP.label "Zeilenschaltung innerhalb eines > Absatzes erzeugt neuen Absatz"> > +<!ENTITY crInPCreatesNewP.label "Enter innerhalb eines Absatzes > erzeugt immer einen neuen Absatz"> > > Enter ist meines Wissens auf dem Mac nicht gebräuchlich. Ich denke > "Zeilenschaltung" ist besser. "Zeilenschaltung" verwendet aber seit der mechanischen Schreibmaschine niemand mehr. "Eingabetaste" ist vielleicht besser, wenn "Enter" wirklich nicht so universell ist, wie es mir vorkommt. > <!ENTITY spaceRadio.label "Abstand"> > > wo ich es gerade sehe: das müsste besser "Leerzeichen" heißen. "Abstand" ist > Unsinn, da das Schriftzeichen "Leerzeichen"/"Space" gemeint ist. So gut ist ein Review ;-) Bin übrigens draufgekommen, dass ich sagor in der alten SeaMonkey-Version "Leerzeichen" hatte, aber das irgendwie beim Konsistenzcheck übersehen hatte. > -<!ENTITY AccessKey.label "Zugriffstaste"> > +<!ENTITY AccessKey.label "Zugriffstaste:"> > > wenn der Doppelpunkt hier hingehört, dann okay (habe den Dialog nicht vor > Augen) Ist zumindest in en-US auch dort. > -<!ENTITY windowTitle.label "Felderbereich-Eigenschaften"> > +<!ENTITY windowTitle.label "Felderbereichs-Eigenschaften"> > > Mit dem "s" tue ich mich immer wieder schwer bei Wortketten. Abdulkadir??? http://de.wikipedia.org/wiki/Fugen-s "Die Verwendung der Fugenlaute folgt dem Sprachgefühl und ist nicht immer einheitlich." :P Für mich klingt es mit dem "s" flüssiger. > -<!ENTITY clear.accesskey "d"> > +<!ENTITY clear.accesskey "L"> > <!ENTITY selectall.accesskey "u"> > -<!ENTITY close.accesskey "l"> > -<!ENTITY cut.accesskey "x"> > -<!ENTITY copy.accesskey "c"> > -<!ENTITY paste.accesskey "v"> > -<!ENTITY props.accesskey "p"> > -<!ENTITY tbar.accesskey "t"> > \ No newline at end of file > +<!ENTITY close.accesskey "c"> > +<!ENTITY cut.accesskey "A"> > +<!ENTITY copy.accesskey "K"> > +<!ENTITY paste.accesskey "E"> > +<!ENTITY props.accesskey "E"> > +<!ENTITY tbar.accesskey "y"> > > wo sind die labels? Das frage ich mich auch. Sollte ich wohl raussuchen ;-) (In reply to comment #5) > -<!ENTITY LabelFor.label "Steuerelement:"> > +<!ENTITY LabelFor.label "Für Steuerelement:"> > > Mir fehlt der Kontext en-US hat "For Control:" Es geht wohl um ein <label for=""> > -<!ENTITY DictionaryList.label "Liste der Wörter:"> > +<!ENTITY DictionaryList.label "Wörter im Wörterbuch:"> > > Ersteres würde ich bevorzugen. Mir gefällt die Doppelung von "Wörter" nicht. Aber ersteres sagt nichts darüber, dass sie im Dictionary sind... > -<!ENTITY docDirList.tooltip "Choose or enter the name of the remote > subdirectory for this page"> > +<!ENTITY docDirList.tooltip "Wählen Sie oder geben Sie den Namen > des externen Unterverzeichnisses für diese Seite ein"> > > Ich würde "Wählen Sie den Namen des externen Unterverzeichnisses dieser Seite > bzw. geben Sie den Namen ein" schreiben. bzw. ist laut Zwiebelfisch meist ein Unwort, und hier ist wirklich ein entweder/oder gemeint. Wie wär's mit "Wählen Sie den Namen des externen Unterverzeichnisses für diese Seite oder geben Sie diesen ein"? Dann haben wir die Wortwiederholung aus deinem Vorschlag auch draußen :) > -<!ENTITY caseSensitiveCheckbox.label "Groß-/Kleinschreibung beachten"> > +<!ENTITY caseSensitiveCheckbox.label "Groß-/Kleinschreibung > berücksichtigen"> > > Erstere Variante finde ich besser und sie ist kürzer, was z.B. in der Findbar > ganz entscheidend ist, da diese teilweise schon auf meinem 19-Zöller zu > breicht wird. Auch wenn wir hier nicht (?) in der Findbar sind, so würde ich > prinzipiell von "beachten" sprechen wollen. "beachten" klingt für mich nach einer Warnung, daher gefällt es mir dort nicht - schließlich geht es darum, ob bei der Suche darauf Rücksicht genommen wird. > -<!ENTITY cellSelectPrevious.label "Vorherige"> > +<!ENTITY cellSelectPrevious.label "Vorhergehende"> > > Meins ist kürzer, Deins klingt besser... Abdulkadir??? Das war der einzige Fall, wo ich irgendwo "Vorherig" aufscheinen hatte, da ich irgendwann alles auf "Vorhergehend" konvertiert hab, weil es in meinem Ohr besser klingt. Alles, was ich nicht näher kommentiert habe, hab ich mal lokal auf deine Vorschläge konvertiert, soweit sie anders als meine sind - mit der Ausnahme von Website/Site, wo ich gerne vom Mozilla-UX-Team hören will, wie sinnvoll die Unterscheidung davon generell ist, und mit der Ausnahme von möchten/wollen, was ich noch als generellen Diskussionspunkt für unsere Synchronisation sehe. Wenn diese zwei Themen sowie oben kommentierte offene Fragen in diesem Review hinreichend geklärt sind, hänge ich nochmals einen ausgebesserten Patch hier an.
(In reply to comment #8) > > -ServerNotAvailable=Der Server ist nicht verfügbar. Kontrollieren Sie Ihre > > Verbindung und versuchen Sie es später nochmals. > > -Offline=Sie sind derzeit offline. Klicken Sie auf das Symbol in der Nähe des > > linken unteren Randes eines Fensters, um online zu gehen. > > +ServerNotAvailable=Der Server ist nicht verfügbar. Überprüfen Sie Ihre > > Verbindung und versuchen Sie es später nochmals. > > +Offline=Sie sind derzeit offline. Klicken Sie auf das Symbol nahe der unteren > > rechten Ecke eines Fensters, um online zu gehen. > > > > In Thunderbird ist das Symbol LINKS unten in der Statusleiste! > > Sicher, auch im Trunk? Ich erinnere mich, dass das auf Grund eines Bugs der > Fall war, obwohl es rechts hätte sein sollen. Der Bug ist IIRC aber > mittlerweile gefixt und es sollte jetzt korrekt rechts unten sein. Würde mich verwundern, links scheint mir die richtige Seite zu sein. Aber eventuell wäre es sowieso besser, sich auf Datei > Offline zu beziehen. > > -NoNamedAnchorsOrHeadings=(Keine Anker oder Überschriften auf dieser Seite) > > +NoNamedAnchorsOrHeadings=(Keine benannten Anker oder Überschriften auf dieser > > Seite) > > > > 2. Variante ist okay (es gab aber einen Grund dafür, dass ich das "benannter" > > weggenommen habe irgendwann - nur leider fällt mir der Grund gerade nicht ein > > - eventuell die Größe des Dialogs? > > Ich hab überlegt, ob ich's ändern soll oder nicht- aber schließlich ist ein > <a> ohne name-Attribut auch ein Anker, aber ein unbenannter, daher hab ich das > zusammenstimmend mit dem en-US eingefügt. Es hat keinen Sinn, das so genau zu nehmen. Ist <p id="foo"> ein "named anchor"? > (In reply to comment #3) > > -<!ENTITY crInPCreatesNewP.label "Zeilenschaltung innerhalb eines > > Absatzes erzeugt neuen Absatz"> > > +<!ENTITY crInPCreatesNewP.label "Enter innerhalb eines Absatzes > > erzeugt immer einen neuen Absatz"> > > > > Enter ist meines Wissens auf dem Mac nicht gebräuchlich. Ich denke > > "Zeilenschaltung" ist besser. > > "Zeilenschaltung" verwendet aber seit der mechanischen Schreibmaschine niemand > mehr. "Eingabetaste" ist vielleicht besser, wenn "Enter" wirklich nicht so > universell ist, wie es mir vorkommt. Eingabetaste ist mir auch sofort in den Sinn gekommen. Zeilenschaltung hab ich noch nie gehört.
(In reply to comment #9) > Aber > eventuell wäre es sowieso besser, sich auf Datei > Offline zu beziehen. Auch dafür sollte man in diesem Fall einen Bug gegen en-US anlegen 8links/rechts ist muss übrigens ebenfalls dort ein Thema sein. Wir dürfen solche Dinge einfach nicht einseitig nur im Deutschen ändern bzw. "ausbessern". > Es hat keinen Sinn, das so genau zu nehmen. Ist <p id="foo"> ein "named > anchor"? Nein, den kann man aber mit dieser Funktion auch nicht erstellen. Wir sind hier im HTML-Composer, falls dir das nicht aufgefallen ist.
(In reply to comment #10) > > Es hat keinen Sinn, das so genau zu nehmen. Ist <p id="foo"> ein "named > > anchor"? > > Nein, den kann man aber mit dieser Funktion auch nicht erstellen. Wir sind hier > im HTML-Composer, falls dir das nicht aufgefallen ist. http://lxr.mozilla.org/mozilla/source/editor/ui/dialogs/content/EdDialogCommon.js#1022
Summary: Update editor L10n after consitency check with suite L10n → Update editor L10n after consistency check with suite L10n
>> -<!ENTITY windowTitle.label "Felderbereich-Eigenschaften"> >> +<!ENTITY windowTitle.label "Felderbereichs-Eigenschaften"> >> >> Mit dem "s" tue ich mich immer wieder schwer bei Wortketten. Abdulkadir??? > > http://de.wikipedia.org/wiki/Fugen-s > "Die Verwendung der Fugenlaute folgt dem Sprachgefühl und ist nicht immer > einheitlich." :P > > Für mich klingt es mit dem "s" flüssiger. Das Fugen-S ist in der Tat eine Anomalie der deutschen Sprache. Momentan ist noch nicht ganz geklärt, warum es auftritt, aber es sind regionale Unterschiede vorhanden. Ich würde auch das Fugen-S in diesem Fall bevorzugen, allerdings nur ohne Bindestrich, beides zusammen wäre mehr oder weniger eine Doppelung. >> -<!ENTITY cellSelectPrevious.label "Vorherige"> >> +<!ENTITY cellSelectPrevious.label "Vorhergehende"> >> >> Meins ist kürzer, Deins klingt besser... Abdulkadir??? > > Das war der einzige Fall, wo ich irgendwo "Vorherig" aufscheinen hatte, da ich > irgendwann alles auf "Vorhergehend" konvertiert hab, weil es in meinem Ohr > besser klingt. Ich würde ich eigentlich sogar Vorige bevorzugen, falls das Gegenstück Nächste heißt. Aber mit Editor hab ich wenig zu tun und würde mich lieber raushalten, da mir die Terminologie nicht so geläufig ist.
(In reply to comment #12) > -<!ENTITY windowTitle.label "Felderbereich-Eigenschaften"> > +<!ENTITY windowTitle.label "Felderbereichs-Eigenschaften"> > http://de.wikipedia.org/wiki/Fugen-s > "Die Verwendung der Fugenlaute folgt dem Sprachgefühl und ist nicht immer > einheitlich." :P > > Für mich klingt es mit dem "s" flüssiger. Aber in einem Wort ist es dann doch etwas lang, finde ich. > -<!ENTITY cellSelectPrevious.label "Vorherige"> > +<!ENTITY cellSelectPrevious.label "Vorhergehende"> > > Ich würde ich eigentlich sogar Vorige bevorzugen, falls das Gegenstück > Nächste heißt. Aber mit Editor hab ich wenig zu tun und würde mich lieber > raushalten, da mir die Terminologie nicht so geläufig ist. Robert, wenn es für Dich okay wäre, dann lass uns "Vorige" verwenden. Ich würde dass in Thunderbird dann auch an anderer Stelle (Nachrichten-Historie) anpassen. "Eingabetaste" ist für mich okay. "Zeilenschaltung" ist in der Tat veraltet und rührt noch aus meiner Schreibmaschinenzeit. Der Online-/Offline-Indikator des 3.0a1-Themes ist (unter Windows) links unten (build von heute). Ist das unter OS X eventuell anders? "Groß-/Kleinschreibung beachten" finde ich nicht wie eine Warnung. Aber ich habe momentan mit Deiner Variante "...berücksichtigen" auch Frieden. "Benutzerwörterbuch", "Status"/"Statusleiste" bzw. alles rund um die Toolbars steht noch zur Diskussion aus. Mit allem Anderen, was Du zuletzt erwähnt hast, bin ich einverstanden.
(In reply to comment #13) > > -<!ENTITY windowTitle.label "Felderbereich-Eigenschaften"> > > +<!ENTITY windowTitle.label "Felderbereichs-Eigenschaften"> > > Aber in einem Wort ist es dann doch etwas lang, finde ich. Warum trennen wir es dann nicht einfach? Mir fehlt zwar jetzt der Zusammenhang, aber wie wäre es denn mit etwas derartigem "Eigenschaften Felderbereich"? > Der Online-/Offline-Indikator des 3.0a1-Themes ist (unter Windows) links unten > (build von heute). Ist das unter OS X eventuell anders? Nein, ist auch links unten. Keine Ahnung, wie es aber bei RTL-Sprachen aussieht. > "Benutzerwörterbuch", "Status"/"Statusleiste" bzw. alles rund um die Toolbars > steht noch zur Diskussion aus. Ein Status ist auch für mich ein x-beliebiger Wert, der irgendwo als Resultat zurückgegeben wird und nicht unbeding im Hauptfenster angezeigt werden muss. Die Statusleiste ist die Leiste am unteren Rand eines Fensters, die Informationen über verschiedene Status enthält.
(In reply to comment #14) > > Der Online-/Offline-Indikator des 3.0a1-Themes ist (unter Windows) links unten > > (build von heute). Ist das unter OS X eventuell anders? > > Nein, ist auch links unten. Keine Ahnung, wie es aber bei RTL-Sprachen > aussieht. Da Deutsch keine RTL-Sprache ist, sollte das keine Rolle spielen ;-) Meine Sorge ist Accessibility, weshalb ich mich eher auf das Menü beziehen würde. Aber wie Robert schon richtig angemerkt hat, betrifft das auch en-US, und sollte wohl nicht unabhängig davon korrigiert werden.
> Warum trennen wir es dann nicht einfach? Mir fehlt zwar jetzt der Zusammenhang, > aber wie wäre es denn mit etwas derartigem "Eigenschaften Felderbereich"? Weil es nicht korrekt ist? > Ein Status ist auch für mich ein x-beliebiger Wert Natürlich wäre ein Status für sich gesehen ein beliebiger Wert. Hier handelt es sich aber um die Auswahl von (ganz eindeutig) Symbolleisten, was sich aus dem Menü / Untermenü ergibt. Trotz allem können wir meinetwegen wieder "Statusleiste" verwenden - dies wird auch in Firefox bisher noch verwendet, da es dort nicht im Untermenü der "Symbolleisten" aufgeführt ist. Die Toolbar in allen Fenstern einfach als "Funktionen" im Untermenü der "Symbolleisten" zu bezeichnen ist meines Erachtens auch okay. Losgelöst vom Untermenü wird natürlich von "Funktionen-Symbolleiste" geredet. Es handelt sich in der Toolbar um nichts anderes als Funktionen, die dort per grafischer Schaltfläche zur Verfügung stehen. Wir können aber auch im Untermenü "Ansicht > Symbolleisten" wieder von "Funktionen-Symbolleiste" reden. Dies würde wieder Firefox entsprechen. "Bearbeiten-Symbolleiste" finde ich persönlich nicht gut, denn z.B. beim Verfassen einer E-Mail wird sie nicht mehr bearbeitet, wenn ich sie sende - sondern es ist eine Funktion, die ich nutze. Daher hatte ich mich konsistent in Thunderbird für "Funktionen" bei der Toolbar entschieden. "Editieren-Symbolleiste" scheint es in Thunderbird nicht zu geben. Die HTML-Funktionen sind in Dialogen versteckt. "Formatierung" finde ich persönlich besser als "Format(-Symbolleiste". Aber auch hier können wir wieder das Wort "Symbolleiste" auch im Untermenü verwenden - auch wenn ich es für "doppelt gemoppelt" halte...
Ach ja, da es gerade um Symbolleisten geht: Bei der Offline-Meldung ist auch zu beachten, dass sich die Statusleiste ausblenden lässt. (In reply to comment #15) > (In reply to comment #14) > > > Der Online-/Offline-Indikator des 3.0a1-Themes ist (unter Windows) links unten > > > (build von heute). Ist das unter OS X eventuell anders? > > > > Nein, ist auch links unten. Keine Ahnung, wie es aber bei RTL-Sprachen > > aussieht. > > Da Deutsch keine RTL-Sprache ist, sollte das keine Rolle spielen ;-) > Meine Sorge ist Accessibility, weshalb ich mich eher auf das Menü beziehen > würde. Aber wie Robert schon richtig angemerkt hat, betrifft das auch en-US, > und sollte wohl nicht unabhängig davon korrigiert werden.
(In reply to comment #17) Stimmt - ein weiterer Grund, sich auf das Menü zu beziehen.
(In reply to comment #13) > > -<!ENTITY cellSelectPrevious.label "Vorherige"> > > +<!ENTITY cellSelectPrevious.label "Vorhergehende"> > > > > Ich würde ich eigentlich sogar Vorige bevorzugen, falls das Gegenstück > > Nächste heißt. Aber mit Editor hab ich wenig zu tun und würde mich lieber > > raushalten, da mir die Terminologie nicht so geläufig ist. > > Robert, wenn es für Dich okay wäre, dann lass uns "Vorige" verwenden. Ich > würde dass in Thunderbird dann auch an anderer Stelle (Nachrichten-Historie) > anpassen. Mir gefällt "vorherige(r/s)" irgendwie als Wort nicht im Hochdeutschen, auch wenn ich im Dialekt gleich "vorige" verwende... Aber vielleicht ist das nur mein Ohr und ich sollte alles wieder zurückändern auf "vorherige"... > Der Online-/Offline-Indikator des 3.0a1-Themes ist (unter Windows) links unten > (build von heute). Ist das unter OS X eventuell anders? Nein. Aber bei SeaMonkey ist er in allen Fenstern rechts unten, weil links unten immer die Komponentenleiste ist. Herrlich, diese Unterschiede, nicht? :-/ Naja, jedenfalls IMHO ein Bug, den wir in en-US lösen müssen, wir sollten jedenfalls nicht eine andere Aussage übersetzen als im Original dort steht. Ich habe Bug 385698 für das Problem im Original angelegt. (In reply to comment #16) > > Ein Status ist auch für mich ein x-beliebiger Wert > > Natürlich wäre ein Status für sich gesehen ein beliebiger Wert. Hier handelt > es sich aber um die Auswahl von (ganz eindeutig) Symbolleisten, was sich aus > dem Menü / Untermenü ergibt. Trotz allem können wir meinetwegen wieder > "Statusleiste" verwenden - dies wird auch in Firefox bisher noch verwendet, da > es dort nicht im Untermenü der "Symbolleisten" aufgeführt ist. Ist es auch in SeaMonkey nicht. Genau deshalb haben wir ja das Problem. Wie gesagt, ich bin dagegen, in der Übersetzung die Aussagen zu ändern. und auch dazu Hinzufügen oder Weglassen von "(tool)bar" bei diesen Bezeichnungen gehört für mich in diese Kategorie. Wenn man es weglassen sollte, dann ist dafür ein Bug im Original anzulegen, und dann folgen wir der Lösung, die dort gefunden wird. Aber eigenständig da "rumzuwurschteln", wie man hier in Wien sagt, finde ich nicht gut. > Die Toolbar in allen Fenstern einfach als "Funktionen" im Untermenü der > "Symbolleisten" zu bezeichnen ist meines Erachtens auch okay. Losgelöst vom > Untermenü wird natürlich von "Funktionen-Symbolleiste" geredet. Es handelt > sich in der Toolbar um nichts anderes als Funktionen, die dort per grafischer > Schaltfläche zur Verfügung stehen. Wir können aber auch im Untermenü > "Ansicht > Symbolleisten" wieder von "Funktionen-Symbolleiste" reden. Dies > würde wieder Firefox entsprechen. "Bearbeiten-Symbolleiste" finde ich > persönlich nicht gut, denn z.B. beim Verfassen einer E-Mail wird sie nicht > mehr bearbeitet, wenn ich sie sende - sondern es ist eine Funktion, die ich > nutze. Daher hatte ich mich konsistent in Thunderbird für "Funktionen" bei der > Toolbar entschieden. Auch hier bleibe ich bei dem, was ich oben gesagt habe: Wenn Thunderbird "Functions" hat, dann heißt es IMHO "Funktionen". Wenn das besser als das aktuelle wäre, dann sollten wir die Änderung im Englischen erwirken, bevor wir sie eigenbrötlerisch nur im Deutschen vornehmen. Mior scheint allerdings, dass wir in diesem Bereich sowieso fast durchgehend über Strings diskutieren, die SeaMonkey-only sind, kann das sein?
So, hier eine aktuellere Version des Patchs - einige Punkte bleiben aber, wie im letzten Kommentar bemerkt, noch offen.
Attachment #269217 - Attachment is obsolete: true
Attachment #272522 - Flags: review?(AlexIhrig)
Attachment #269217 - Flags: review?(AlexIhrig)
+<!ENTITY decreaseZIndex.label "In den Hintergrund senden"> Hier hast Du im Patch an anderer Stelle "....stellen" geschrieben, was ich persönlich besser finde. Was mir persönlich schwer im Magen liegt ist der Offline-Indikator rechts/links unten. Für Thunderbird wird das zumindest momentan zu einem eindeutigen Bug und somit erstmal Rückschritt im Deutschen. Aber ich verstehe Dein Argument, dass man das generell für alle Sprachen anpassen muss. Außerdem finde ich "Wörterbuch" statt "Benutzerwörterbuch" beim Hinzufügen von neuen Wörtern einfach undeutlicher und somit für die Anwender einen Rückschritt. Die sind sich nicht mehr im Klaren darüber, wo (in welcher Datei) die eigenen Wörter gespeichert werden. Auch das ist ein Rückschritt für den das gleiche wie oben gilt. Ansonsten bin ich mit allem einverstanden - ich kann mit den verschiedenen kleinen Änderungen leben. Schließlich ist alles für ein Major-Update und Du bringst uns endlich auf einen relativ kompletten Stand der Trunk-Übersetzung. Danke Robert
Attachment #272522 - Flags: review?(AlexIhrig) → review+
Comment on attachment 272522 [details] [diff] [review] Patch for syncing of editor part of German L10n, v2 Hier noch ein paar Anmerkungen von meiner Seite... >Index: l10n/de/editor/ui/chrome/composer/editorOverlay.dtd > <!ENTITY dumpContentCmd.label "Dump Content Tree"> > <!ENTITY runUnitTestsCmd.label "Run Unit Tests"> > <!ENTITY dumpUndoStack.label "Dump Undo Stack"> > <!ENTITY dumpRedoStack.label "Dump Redo Stack"> Haben wir keine deutsche Übersetzung dafür? >Index: l10n/de/editor/ui/chrome/dialogs/EditorPublish.dtd >+<!ENTITY newSiteButton.label "Neue Website"> Bezieht sich das wirklich auf eine komplette Website? Nachfolgende Übersetzungen wären davon auch betroffen. >+<!ENTITY docDirList.tooltip "Wählen Sie den Namen des externen Unterverzeichnisses für diese Seite oder geben Sie diesen ein"> ... hier haben wir dann nur Seite. >Index: l10n/de/editor/ui/chrome/dialogs/EditorPublishProgress.dtd >-<!ENTITY siteUrl.label "Site-URL:"> >+<!ENTITY siteUrl.label "Website-URL:"> > <!ENTITY docSubdir.label "Unterverzeichnis für die Seite:"> Wirklich Website? Weiterhin gibt es jede Menge Accesskeys, die nicht der Klein-/Großschreibung folgen. Keine Ahnung, ob es da Kollisionen gibt aber das sollte auch korrigiert werden. Wollen wir das in einem separaten Bug durchführen, wenn dein Patch eingecheckt wurde, Robert`?
(In reply to comment #21) > +<!ENTITY decreaseZIndex.label "In den Hintergrund senden"> > > Hier hast Du im Patch an anderer Stelle "....stellen" geschrieben, was ich > persönlich besser finde. OK, wird gemacht. > Was mir persönlich schwer im Magen liegt ist der Offline-Indikator > rechts/links unten. Für Thunderbird wird das zumindest momentan zu einem > eindeutigen Bug und somit erstmal Rückschritt im Deutschen. Aber ich verstehe > Dein Argument, dass man das generell für alle Sprachen anpassen muss. Klar, dass das ein Bug für Thunderbird ist. Daher sollten wir Bug 385698 jedenfalls vor dem trunk-Release gelöst bekommen. > Außerdem finde ich "Wörterbuch" statt "Benutzerwörterbuch" beim Hinzufügen > von neuen Wörtern einfach undeutlicher und somit für die Anwender einen > Rückschritt. Die sind sich nicht mehr im Klaren darüber, wo (in welcher > Datei) die eigenen Wörter gespeichert werden. Auch das ist ein Rückschritt > für den das gleiche wie oben gilt. Sollten wir für diese Fälle auch generelle Bugs anlegen? An sich geht es ja um spellCheckAddToDictionary.label und da ist im Original auch "Add to Dictionary". "Zu Benutzerwörterbuch hinzufügen" ist allerdings schon arg lang für ein Kontextmenü. :( Ich wollte gerade nachsehen, was OOo bei derartigen Fällen verwendet, aber das meldet sich im Moment nur auf Englisch hier. Dort haben sie allerdings nur "Add >" im Kontextmenü, mit einer Auswahl der Dateinamen der Benutzerwörterbücher im Submenü - also normalerweise "Add > standard.dic" - Ob das besser ist, weiß ich nicht ;-) (In reply to comment #22) > > <!ENTITY dumpContentCmd.label "Dump Content Tree"> > [...] > > Haben wir keine deutsche Übersetzung dafür? Ist Debug-UI, da brauchen wir keine - und Bug 381343 verschiebt die sowieso in die debugQA-Extension. > >Index: l10n/de/editor/ui/chrome/dialogs/EditorPublish.dtd > >+<!ENTITY newSiteButton.label "Neue Website"> > > Bezieht sich das wirklich auf eine komplette Website? Nachfolgende > Übersetzungen wären davon auch betroffen. Ja, man legt in diesem Fall auch eine neue Adresse an, wohin publiziert werden soll, also passt das schon. Hat schon einen Grund, warum auch das Original da "Site" verwendet. ;-) > >+<!ENTITY docDirList.tooltip "Wählen Sie den Namen des externen Unterverzeichnisses für diese Seite oder geben Sie diesen ein"> > > ... hier haben wir dann nur Seite. Ja, weil da geht es um um das Unterverzeichnis der Site, in dem die gerade bearbeitete Seite gespeichert wird. > >Index: l10n/de/editor/ui/chrome/dialogs/EditorPublishProgress.dtd > > >-<!ENTITY siteUrl.label "Site-URL:"> > >+<!ENTITY siteUrl.label "Website-URL:"> > > <!ENTITY docSubdir.label "Unterverzeichnis für die Seite:"> > > Wirklich Website? Ja. Obwohl ich zugebe, dass diese Publish-Dialoge etwas verwirrend wirken in dieser Hinsicht. Ist aber im Original nicht anders... > Weiterhin gibt es jede Menge Accesskeys, die nicht der Klein-/Großschreibung > folgen. Keine Ahnung, ob es da Kollisionen gibt aber das sollte auch korrigiert > werden. Wollen wir das in einem separaten Bug durchführen, wenn dein Patch > eingecheckt wurde, Robert`? Ja, weitere Accesskey-Korrekturen sollten wir separat machen. Einige, über die ich gestolpert bin, hab ich hier korrigiert, aber es gibt sicher eine Menge mehr - da stammen manche noch aus den Zeiten, wo es diese Unterscheidung noch gar nicht gab...
(In reply to comment #23) > > >Index: l10n/de/editor/ui/chrome/dialogs/EditorPublish.dtd > > >+<!ENTITY newSiteButton.label "Neue Website"> > > Ja, man legt in diesem Fall auch eine neue Adresse an, wohin publiziert werden > soll, also passt das schon. Hat schon einen Grund, warum auch das Original da > "Site" verwendet. ;-) > > > >+<!ENTITY docDirList.tooltip "Wählen Sie den Namen des externen Unterverzeichnisses für diese Seite oder geben Sie diesen ein"> > > > > ... hier haben wir dann nur Seite. > > Ja, weil da geht es um um das Unterverzeichnis der Site, in dem die gerade > bearbeitete Seite gespeichert wird. Wie und wo lege ich dann eine einzelne Seite an? Ich kenne den Editor nicht, deshalb meine Frage, wo finde ich den Menüpunkt? > Ja, weitere Accesskey-Korrekturen sollten wir separat machen. Einige, über die > ich gestolpert bin, hab ich hier korrigiert, aber es gibt sicher eine Menge > mehr - da stammen manche noch aus den Zeiten, wo es diese Unterscheidung noch > gar nicht gab... Wie sollen wir die entsprechenden Bugs anlegen? Sollen Sie auf diese hier aufbauen? Auch am besten komponentenbasiert anlegen? Wie kann man denn dann am schnellsten auf Konflikte testen?
(In reply to comment #24) > Wie und wo lege ich dann eine einzelne Seite an? Ich kenne den Editor nicht, > deshalb meine Frage, wo finde ich den Menüpunkt? Der Editor bearbeitet immer ein einzelnes Dokument, also eine Seite - also File > New Composer Page erstellt eine neue Seite. Die Publish-Dialoge kennen Einstellungen für Sites zum Publizieren dieser Seiten. > Wie sollen wir die entsprechenden Bugs anlegen? Sollen Sie auf diese hier > aufbauen? Auch am besten komponentenbasiert anlegen? Wie kann man denn dann am > schnellsten auf Konflikte testen? Konflikte kann man am besten testen, in dem man die Menüs und Dialogs händisch durchschaut - eine andere Möglichkeit gibt es leider nicht... Bugs am besten in kleineren Happen, pro Dialog/Menü anlegen - und am besten gleich mit Vorschlägen für bessere Accesskeys statt denen, die einen Konflikt darstellen. Ich hab jetzt den bearbeiteten Stand eingecheckt. Mir wird dieser Bug langsam zu unübersichtlich für weitere Arbeiten an den hier aufgedeckten Problemen - können wir dafür neue Bugs anlegen, so wie wir diese Probleme finden?
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: