Ich habe das zwar mal so in der JSON gelassen, aber im Prinzip kann man es auch herausnehmen.
Schaut momentan bei mir so aus und funktioniert perfekt:
Und so sieht es auch aus. :klasse:
Stimmt doch so, hoffe ich... :lol:
Ja, genau.
Danke nochmal, Sören.
Das war jetzt mal richtig effektive Hilfe. :klasse:
Dem kann ich mich nur anschließen. :klasse:
Sehr, sehr herzlichen Dank euch beiden.
Und auch dir nochmal ein dickes Dankeschön. 
Und so schaut's aus...
sorbisch.png
Ein Traum wurde wahr. :klasse:
Gibt es eigentlich ein Emoticon für Freudentränen?
Da haben wir es schon: ?
:lol::lol::lol: Es fehlt ein rollendes Smilie... 
Da finde ich im Moment auch kein passendes.
Vielleicht das:
[attachment=0]rollender_Smilie_3.gif[/attachment]
Ich habe gerade in meinem Postfach gelesen (kam von mozill@e-mozilla.org), dass vom 18.06 bis 02.07. eine Kampagne zur Übersetzung von Add-ons stattfinden soll. Mal sehen, vielleicht beteilige ich mich. Sie schreiben allerdings von den "top 11 languages". Da gehört Sorbisch garantiert nicht dazu.
let tabsLength = tabs.length; let rule = new Intl.PluralRules( locale ).select( tabsLength ); var tabsNum = browser.i18n.getMessage('Tab_'+(rule)); tabsCount.textContent = ' (' + tabsLength + ' ' + tabsNum + ')';
Anmerkung dazu: Du kannst Variablen mit const, let oder var definieren. In modernem JavaScript verwendet man üblicherweise überhaupt kein var mehr. Und wenn du eine Variable später nicht mehr überschreibst, solltest du const statt let verwenden.
Mehr Hintergrund dazu:
https://medium.com/javascript-sce…st-ba58b8dcde75
Eine Frage zu den nicht genutzten Pluralkategorien, Sorbisch nutzt kein MANY. Da müsste ich den Originaltext praktisch rauslöschen und nur die Anführungszeichen stehen lassen?
Im Prinzip ist es egal, was darin steht, weil das halt einfach nicht verwendet wird. Ich würde vermutlich die "other"-Form auch für die nicht verwendeten Formen verwenden, damit es nicht so aussieht, als wäre eine Übersetzung vergessen worden, aber ein leerer Inhalt ergibt genauso Sinn. Also da kann EffPeh entscheiden, was ihm besser gefällt. Es sollte nur konsistent bei allen Sprachen sein, weil es sonst Chaos ist. 
OK. Danke. Letztendlich muss der Übersetzer die Regeln kennen, egal, ob Englisch einen Text oder einen leeren String verwendet. Er muss wissen, durch wass er es zu ersetzen hat.
Das wäre ein Fall für einen Kommentar, aber leider lässt JSON keine Kommentare zu.
Aber die Übersetzungs-Architektur von WebExtensions lässt Kommentare zu.
Du siehst vermutlich immer nur dieses Schema:
"localization_key": {
"message": "Übersetzung"
}Die Dokumentation sieht aber noch ein weiteres Feld vor:
"localization_key": {
"message": "Übersetzung",
"description": "Hier kann ein beliebiger Kommentar zur Übersetzung stehen"
}
Aber die Übersetzungs-Architektur von WebExtensions lässt Kommentare zu.Du siehst vermutlich immer nur dieses Schema:
Ja.
Die Dokumentation sieht aber noch ein weiteres Feld vor:
Wird der Text aber dann nicht auch auf der Benutzeroberfläche angezeigt?
Nein, das ist ein reines Kommentarfeld, welches genau für solche Übersetzungs-Hinweise gedacht ist.
EffPeh:
Würdest du ein Kommentar-Entity einbauen? Könnte etwa so aussehen:
"Comment": {
"message": "LOCALIZATION NOTE"
"description": Please specify the correct plural forms in the Tab_zero, Tab_one, Tab_one, Tab_two, Tab_few, Tab_many, Tab_other. If a plural form is not used in your language, leave the string empty."
}@Sören:
Ich hoffe, man kann das als gesondertes Entity machen. Oder muss man description bei allen betroffenen Entities angeben?
EffPeh: Ich schlage vor, dass du das Entity Tab_others in Tab_other umbenennst. Die CLDR-Kategorie heißt OTHER, abgesehen mal davon, dass Adjektive im Englischen gar keinen Plural bilden können.
Ich würde das ehrlich nicht so machen wie in deinem Code-Beispiel oben, weil das so nicht gedacht ist. Technisch wäre das zwar möglich, weil man die Übersetzung im Code ja nicht verwenden muss, aber ich bin der Meinung, dass es verwirrend ist, wenn man Dinge falsch verwendet. Dann bräuchte es zusätzlich noch einen Hinweis für den Übersetzungs-Hinweis, wie der Übersetzungs-Hinweis gedacht ist und dass der nicht zu übersetzen ist…
Also bei allen angeben? Den String kann man ergänzen, etwa You need not translate this string. LOCALIZATION NOTE könnte man auch in description aufnehmen:
"description": "LOCALIZATION NOTE: Please specify the correct plural form for this category. If this plural form is not used in your language, leave the string empty. You need not translate this string."
Guten Morgen...
Anmerkung dazu: Du kannst Variablen mit const, let oder var definieren. In modernem JavaScript verwendet man üblicherweise überhaupt kein var mehr. Und wenn du eine Variable später nicht mehr überschreibst, solltest du const statt let verwenden.
Ja, ich weiss. Wir hatten das Thema schon einmal. Ich versuche mich daran zu halten, aber gerade wie hier, wenn ich was neues austesten will, verfalle ich schnell wieder in alte Muster. Und in Beispielen (auch bei MDN) wird var auch noch relativ häufig verwendet und ich übernehme das dann manchmal, weil mein Hirn noch nicht auf let getrimmt ist.
Aber ich verspreche, dass du im Update, das ich im Laufe des Tages bei Github einstelle, kein einziges var mehr finden wirst. :wink:
Aber die Übersetzungs-Architektur von WebExtensions lässt Kommentare zu.
Und ich wünschte, das würde man ganz allgemein für JSON einführen... :wink:
EffPeh: Ich schlage vor, dass du das Entity Tab_others in Tab_other umbenennst. Die CLDR-Kategorie heißt OTHER, abgesehen mal davon, dass Adjektive im Englischen gar keinen Plural bilden können.
Das ist schon längst geschehen - sonst hätte das gestern mit dem Sorbisch auch nicht hingehauen. War nur ein Schreibfehler, wahrscheinlich hat mein Hirn da einen Sprung zu "The Others" gemacht.
EffPeh:
Würdest du ein Kommentar-Entity einbauen? Könnte etwa so aussehen:
Ich könnte überall dort, wo es darum geht, eine Beschreibung/Anmerkung einfügen, also etwa so:
"Tab_one": {
"message": "rajtark",
"description": "Please specify the correct plural form for category one"
},
"Tab_two": {
"message": "rajtarkaj",
"description": "Please specify the correct plural form for category two"
},
Ich schätze, ein Übersetzer sollte dann wissen, was zu tun ist, oder?...
Also bei allen angeben? Den String kann man ergänzen, etwa You need not translate this string. LOCALIZATION NOTE könnte man auch in description aufnehmen:"description": "LOCALIZATION NOTE: Please specify the correct plural form for this category. If this plural form is not used in your language, leave the string empty. You need not translate this string."
Oder so. Im Prinzip musst du das als Übersetzer wissen. Für mich ist das nur Copy&Paste...
> Ich schätze, ein Übersetzer sollte dann wissen, was zu tun ist, oder?...
Ich behaupte mal, dass der Großteil nicht die geringste Ahnung hat. Geh mal mit folgender Denkweise heran: weißt du von der deutschen Sprache, dass es eine "Kategorie "one" und eine Kategorie "other" gibt? Andere wissen das von ihrer Sprache auch nicht. Sie kennen die Regeln ihrer Sprache, wissen aber vermutlich nicht, was du mit "category one" und "category two" meinst.
Vielleicht gibst du den einen Link an dieser Stelle mit an, den du von milupo genannt bekommen hast und der diese Regeln erklärt.
Hier ein paar Erläuterungen zu Git und Sourcetree.
Ich möchte dir eine wirklich einfache Einführung geben, daher verzichte ich auf einige Begriffe und Details wie "Stage", "HEAD" usw. Ich konzentriere mich in dieser Erklärung einzig und alleine darauf, was für die Arbeit mit Sourcetree wichtig ist. Tiefergehende Erklärungen zu Git findest du im Web wie Sand am Meer und ich empfehle sehr, entsprechende Lektüre zu lesen. Das Thema Git füllt ganze Bücher, wenn du wirklich ins Detail gehen und erweiterte Konzepte lernen möchtest.
Begrifflichkeiten:
Repository: Das Repository beinhaltet sämtliche Dateien und Änderungen. Wenn du mit Git arbeitest, musst du zwischem lokalen Repository und Remote-Repository unterscheiden. Das lokale Repository ist auf deinem Computer und gehört nur dir, das Remote-Repository liegt in deinem Fall auf github.com.
Commit: Wenn du Dateien änderst, neu hinzufügst oder löschst, musst du diese Änderungen committen. Das bedeutet, dass du die Änderungen in dein lokales Repository überträgst.
Push: Der Push bezeichnet die Übertragung vom lokalen Repository in das Remote-Repository. Du kannst beliebig viele Änderungen erst einmal in dein lokales Repository committen und dann später gemeinsam in das Remote-Repository pushen.
Pull: Änderungen von deinem Remote-Repository in deine lokale Arbeitskopie bringen, also praktisch das Gegenteil von Push. Wird vermutlich nur ein Faktor, wenn jemand weiteres sich an deinem Projekt beteiligt, aber vielleicht auch, wenn du alleine bleibst und irgendwann mal was von einem anderen Computer aus pushst und dementsprechend die Änderungen nicht auf deinem ursprünglichen Computer hast.
---
Workflow:
Du arbeitest ganz normal an deinen Dateien, fügst neue Dateien hinzu, löschst Dateien. Das machst du mit welchem Programm auch immer du willst. In Sourcetree siehst du dann links unter "Dateistatus" welche Dateien neu, gelöscht oder geändert sind. Das ist unterteilt in "vorgemerkte Dateien" oben und "nicht vorgemerkte Dateien" unten. Dort wählst du alles aus, was du in das lokale Repository committen möchtest. Per Checkbox für alle Änderungen in der Datei oder über entsprechende Buttons rechts auch nur für einzelne Blöcke, wenn du an einer Datei mehrere Sachen bearbeitet hast. Markierst du Zeilen kannst du sogar nur einzelne Zeilen auswählen. Alles, was du vormerkst, verschwindet von unten und wandert nach oben zu den "vorgemerkten Dateien".
Ganz wichtig: gib beim Commit-Kommentar unten eine aussagekräftige Beschreibung deiner Änderungen an. Auf eine Beschreibung zu verzichten oder einen Schmarn wie "Änderungen" oder "Bugfix" zu schreiben, ist technisch kein Problem, aber ein wirkliches No-Go, denn das bringt niemandem etwas, weder dir noch anderen. Man muss anhand der Beschreibung eine Idee davon erhalten können, was du getan hast. Das ist der Sinn des Commit-Kommentars. Das ist das, was später auf Github in den Commits als Titel steht und auf deine Änderungen verlinkt.
Auch ganz wichtig: Bevor du irgendetwas committest: schau dir deine Änderungen an. Das ist mit das Tollste überhaupt, dass du alle deine Änderungen siehst. Diese Funktion hat schon in so vielen Projekten so viele Fehler verhindert. Du hast einfach eine ganz andere Wahrnehmung, wenn du deine Änderungen wirklich siehst und nicht nur eine ungefähre Vorstellung davon hast, was du inhaltlich ungefähr getan hast. Auch wenn es deine eigenen Änderungen sind und meinst, es eigentlich wissen zu müssen, es bringt dir echt viel, glaub mir.
Am Ende klickst du nur noch auf den Button "Commit" und fertig, die Änderungen sind committet (aber noch nicht auf GitHub!)
Um die Änderungen in das Remote-Repository auf Github zu bringen, klickst du oben in der Symbolleiste nun auf Push. Du wirst in der Regel von deinem lokalen master-Branch auf den Remote-Branch master pushen und musst daher nichts weiter anpassen, einfach "OK" klicken, fertig. Die Änderungen sind nun auf GitHub.
Du kannst, bevor du commitest, auch die Checkbox "Änderungen sofort nach xxx pushen" auswählen. Dann hast du den Commit und den Push in einem Schritt, musst oben also nicht mehr auf Push klicken. Das ist genau das Gleiche, nur eine Abkürzung.
Und zum Pull zum Beziehen von Änderungen aus dem Remote-Repository, falls du das mal benötigst: das ist einfach der Button "Pull", der direkt neben "Push" ist.
---
Im Endeffekt ist es das schon, damit kommst du für den Anfang schon sehr weit. Es gibt noch einige andere Konzepte, die zu Git gehören und unheimlich praktisch sind, u.a. Tags, Branches, Merges, Rebases, Stashes, aber darüber brauchen wir erst zu reden, wenn du das hier verinnerlicht hast und über diese Dinge nicht mehr nachdenken musst.