Posted by Sabine Mehrens on March 19, 2011 at 10:58am
4 followers
Jump to:
| Project: | German translation |
| Version: | master |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Nun bin ich ja erst ganz kurz dabei, und mir fallen einige Kleinigkeiten auf, die den alten Hasen wahrscheinlich klar sind. Ich frage mal ganz naiv. Unter anderem:
Manchmal entspricht der Übersetzungsvorschlag - und dann auch die Übersetzung - 1:1 dem Original.
Häufig zum Beispiel bei technischen Abkürzungen, Markennamen, geografischen Namen.
- Kommen solche Dinge nur zustande, weil der Entwickler nicht über den Sinn einer Übersetzung nachdenkt und sicherheitshalber einfach immer Strings mit t() übersetzbar macht? Oder ist es einfach so, dass es in einigen Ländern, für einige Benutzer, Sinn machen könnte, diese Dinge zu übersetzen, für die meisten aber nicht?
- Wenn solche Fälle auftreten, soll man dann eine 1:1 Übersetzung erstellen, oder den Begriff lieber unübersetzt lassen?
- Gibt es Auswirkungen auf Performance, Installation, sonst irgendetwas?
- Führt die Tatsache, dass es eine 1:1 Übersetzung gibt, dazu, dass sich niemand mehr Gedanken über diesen "nicht übersetzten Begriff" machen muss, d.h. es muss übersetzt werden, um den Arbeitsablauf im Griff zu behalten?
- Erscheinen 1:1 Übersetzungen in den .PO Dateien? Wäre es sinnvoll, sie da herauszufiltern?
- Gibt es einen eigenen Cache-Mechanismus für Strings? Wenn ja, wie funktioniert er? Wenn nein, warum nicht?
- Erscheinen 1:1 Übersetzungen (und auch ganz normale andere übersetzbare Strings) in jedem neuen Release wieder in "unübersetztem" Zustand? Wenn ja, welchen Sinn hat das?
- Weshalb werden einige Strings in mehreren, ganz unterschiedlichen Modulen benutzt? Kann man das ändern?
Bin gespannt, ob mir da jemand zu etwas mehr Klarheit verhelfen kann.
LG Sabine
Comments
#1
Hallo Sabine,
vielen Dank für Deine Fragen. Ich finde diese sinnvoll, weil daraus einfach mehr über die Funktionsweise des Übersetzungssystems klar wird.
1.) Die Frage beantwortet sich sofort, wenn Du z.B. an Sprachen denkst, die von rechts nach links geschrieben werden. Wenn der Entwickler die Option zur Übersetzung anbietet, dann kann die originale Zeichenkette übersetzt werden - bietet der Entwickler die Möglichkeit nicht an, dann ist der Aufwand für den Administrator einer Site viel höher.
2.) Ich versuche die Übersetzung in der Regel für jedes Modul vollständig zu machen, dann habe ich einen besseren Überblick, ob noch was fehlt. Rein technisch könnten wir auf eine Übersetzung Marke -> Marke verzichten.
3.) Auswirkung auf die Performance: wahrscheinlich so gut wie keine. Installation: Die Übersetzung werde ich ohnehin einspielen, ob jetzt ein String mehr oder weniger drin ist.
4.) für mich der entscheidende Punkt: das Modul ist vollständig übersetzt. Ansonsten könnte es passieren, dass einzelne Übersetzer jedesmal prüfen, was genau noch nicht übersetzt ist.
5.) Herausfiltern würde zuviel Aufwand bedeuten und hätte praktisch gesehen keine Vorteile.
6.) Strings werden gecached: http://api.drupal.org/api/drupal/modules--locale--locale.module/function...
(sollte das nicht reichen, gibt es eine große Zahl Module, die cachen bzw. Konzepte Cache (-Kaskaden) aufzubauen).
7.) Übersetzungen werden durch localize.drupal.org automatisch für alle Versionen zur Verfügung gestellt: Wir ein String für eine Version übersetzt, so gilt diese Übersetzung für alle Versionen eines Moduls.
8.) Jeder Entwickler kann den Text in der Benutzeroberfläche seines Moduls schreiben, wie er möchte. Dadurch kommt der Effekt zustande, dass manchmal für den gleichen Sachverhalt unterschiedliche Strings verwendet werden (was mehr Übersetzungsaufwand bedeutet) oder die gleichen Strings für unterschiedliche „Dinge“ verwendet werden. Ein Beispiel im Deutschen: Bank wird z.B. als Bezeichnung für ein Geldinstitut und für eine Sitzmöglichkeit verwendet. Natürlich gibt es auch solche Beispiele im Englischen und man bräuchte dafür zwei verschiedene Übersetzungen im Deutschen. Mit Drupal 7 ist es jetzt möglich „Kontexte“ für die Übersetzung zu verwenden.
Leider gibt es noch keine Liste häufig gebrauchter Kontexte …
Also Übersetzung sieht einfach aus und ist im Detail dann doch ganz schön knifflig.
#2
Vielen Dank für die schnellen Antworten,
nun sehe ich schon etwas klarer - bis auf Punkt 8 (bei mir dauert es immer etwas länger) ...
Die Oberfläche mit der Auswahl nach Modulen und Releases erweckte bei mir den Eindruck, dass ein Begriff auch in Drupal 6 mit zwei verschiedenen Übersetzungen auftauchen kann, wenn er denn aus zwei verschiedenen Modulversionen stammt.
Beim Blick in die Datenbank finden sich in der Drupal 6.20 Version in der Tabelle locales_source auch Felder wie location, textgroup und version, die bei mir den Eindruck verstärkten, dass Drupal einen String doch einer Modulversion zuordnen kann (und das auch tut?).
Insofern wäre das Modul der primäre Context, sozusagen, auch wenn das erst in Release 7 kommt.
Aber vielleicht werden diese Felder in der Datenbank für die eigentliche Übersetzung gar nicht benutzt, und dienen nur zur Vorbereitung des zukünftigen Releasewechsels?
Wenn ich einen Blick auf die Dolumentation des Locale-Moduls werfe, fürchte ich fast, so ist es. Denn die Übersetzungsroutine bekommt nur den String selbst, und die Sprache, oje, o.k., leider.
Nehmen wir ein Beispiel: "capital" bedeutet im Adressen-Modul "Hauptstadt", in einem Bank-Modul vielleicht "Kapital" (Geld).
Habe ich nun keine Chance auf eine vernünftige Übersetzung für so einen Ein-Wort-String? Wirkt sich die Übersetzung automatisch auf das aus, was in beiden Modulen letztlich ausgegeben wird?
Anscheinend ist es so. Wie gesagt, etwas schwer von Begriff, sorry.
Vielen Dank für die Erklärung
Sabine
#3
#4
Automatically closed -- issue fixed for 2 weeks with no activity.