Vorschlag: Übersetzungs-Tool für ReactOS

Hier können Sie auf Deutsch diskutieren. Bedenken Sie, dass Sie in den englischen Foren mehr Nutzer ansprechen.

Moderators: frik85, EmuandCo, Dr. Fred

ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Vorschlag: Übersetzungs-Tool für ReactOS

Post by ma-games.de »

Dieser Post ist sehr lang und für Leute gedacht, die Interesse daran haben, dass die Weiterentwicklung von ReactOS verbessert wird. Um allen anderen ihre Zeit zu sparen, können sie an dieser Stelle das Lesen abbrechen. :wink:

Im Thread ReactOS in Deutsch bin ich auf eine Idee gekommen, welche die Übersetzung und damit den Weg Mehrsprachigkeit von ReactOS vereinfachen soll.

Ich habe mir nun die aktuellen .rc-files angeschaut, in denen die Übersetzungen für ReactOS stehen. Ich habe festgestellt, das es für manche Verzeichnisse schon relativ viele Sprachfiles gibt, bei anderen nur sehr wenige. Deutsch und auch Spanisch sind z.B. schon sehr gut vertreten. Bei Russisch, Ungarisch oder Finnisch sieht es dagegen noch recht mau aus und viele Sprachen sind überhaupt noch nicht dabei.
Daher frage ich mich wie das im Moment eigentlich mit den Übersetzungen gemacht wird. Ich denke mal das man sich das englische rc-file holt und dann in einem Texteditor die betreffenden Stellen in seine Sprache übersetzt.

Wenn das allerdings so praktiziert wird hat dieses Verfahren doch einige Nachteile:
  1. Leute die noch nie etwas mit Quellcode in ihrem Leben zu tun hatten werden es sehr schwer haben die betreffenden Dateien und Stellen zu finden, die übersetzt werden müssen. Hierzu gibt es im Thread ReactOS in Deutsch auch einen entsprechenden Benutzer-Eintrag:
    loki1985 wrote:ich wäre gerne bereit an einer deutschen übersetzung mitzuhelfen, sofern der ganze text / die strings in einem externen file ausgelagert sind. direkt im source rumzupfuschen wäre IMHO nicht so vorteilhaft...
  2. Man muss relativ lange in den Verzeichnissen suchen um Dateien zu finden die noch nicht übersetzt wurden.
  3. Es ist problematisch eine Datei nur "halb" zu übersetzen (weil man z.B. einige Wörter nicht weiß) und sie dann in das CVS zu stellen.
  4. Der gesamte Status der Übersetzung ist schwer zu erkennen. Es ist nicht ablesbar wieviel Prozent einer Sprache schon implementiert wurden.
  5. Manche Übersetzungen sind unglücklich oder falsch. Es dauert relativ lange solche Fehler zu finden. (z.B in der Datei cdlg_DE.rc: Hier wurde der String "PD32_PRINTER_STATUS_OFFLINE" in Deutsch mit "Printer ist offline; " übersetzt. Natürlich ist das nicht dramatisch aber dennoch unglücklich: Alle anderen Strings in dieser Datei in denen das englische Wort "Printer" vorkommt, wurden mit "Drucker" übersetzt. Die Übersetzung ist in diesem Fall also nicht Konsistent und außerdem würde ich "Printer" noch nicht als "eingedeutscht" bezeichnen. Es sollte daher übersetzt werden. So evtl. auch das Wort "offline".)
Durch diese Nachteile werden also viele Leute daran gehindert an der Übersetzung mitzuarbeiten weil sie sich zu wenig mit CVS und Quellcode auskennen. Auch die Leute, die nur hin und wieder mal ein paar Wörter oder Sätze übersetzen möchten, habe es so sehr schwierig, da erst sehr lange nach den Dateien gesucht werden muss und dann immer gleich eine ganze Datei bearbeitet werden sollte. Außerdem dauert es lange bis Fehler und Inkonsistenzen entdeckt werden.

Wenn nun also die oben genannte Bearbeitungsweise zutrifft hätte ich folgenden Vorschlag:
Es müsste ein zentrales Übersetzungstool für ReactOS geben, das webbasiert, einfach und damit für jeden zugänglich ist.

Ich stelle mir vor, das ein USE-CASE dafür ungefähr so funktioniert:
  1. Man wählt aus in welche Sprache man übersetzen will.
    • es erscheinen alle Dateien mit der Angabe wieviel Prozent schon übersetzt sind
  2. Man wählt eine Datei aus die man übersetzen will.
    • es werden nun alle Strings aufgelistet:
      • mit Variablen-Name
      • evtl. Beschreibung der Bedeutung
      • der englische Text
      • einem editierbaren Textfeld, das entweder leer ist wenn es noch keine Übersetzung gibt, oder wo das bisherige übersetzte Wort darin steht
  3. Man bestätigt die Übersetzung
Natürlich kann man nicht einfach den CVS-Tree durch das Tool automatisch auslesen lassen und die Strings importieren. Dafür ist der Aufbau der .rc-files einfach zu kompliziert. Es müssten daher die Leute, die sich mit den Dateien auskennen, einmalig die Arbeit machen und die Strings aus einer Datei heraus zu schreiben und mit der Beschreibung und dem englischen Text in die Datenbank des Tools eingeben.
Zu gewissen Zeitpunkten (eine neue ReactOS Version, oder wann immer es gewünscht ist) werden dann die Dateien in das ReactOS-CVS zurück importiert.
Ein weiteres Feature dieses Tools könnte sein, dass aus dem aktuellen Datenbank-Bestand der Status der jeweiligen Übersetzungen berechnet wird. Zum Beispiel in dieser Form:

Code: Select all

German: 97% of translation completed
Spanisch: 89% of translation completed
...
Das wäre dann auch für die einzelnen Dateien möglich:

Code: Select all

cdlg_En.rc: 100% of translation completed
cdlg_De.rc: 67% of translation completed
...
Und natürlich auch alle benötigten Dateien in einer bestimmten Sprache:

Code: Select all

comctl_Fr.rc: 100% of translation completed
cdlg_Fr.rc: 0% of translation completed
...
Durch dieses Schema könnte man schnell erkennen welche Übersetzungen noch fehlen und muss sich nicht erst lange durch den CVS-Tree wälzen.

Die Vorteile eines solchen Übersetzungs-Tools noch einmal kurz zusammengefasst:
  • Mithilfe an der Übersetzung durch wesentlich mehr Leute
  • keine komplette Bearbeitung eines Files zwingend erforderlich
  • schnellere Übersetzung durch vereinfachtes Handling
  • komfortable Übersicht über den Fortschritt der Übersetzung
  • bessere Kontrolle und Fehlerkorrektur über die Übersetzung
  • leichtere Erweiterbarkeit der Files durch neue Strings möglich
Natürlich gibt es auch Risiken und Probleme bei meinem Vorschlag über die man sich Gedanken machen müsste.

Im Moment fällt mir da zum Beispiel Folgendes ein:
Was ist wenn es Änderungen an den grafischen Benutzer-Elementen wie Buttons, Labels usw. in einer .rs-Datei gibt, die Datei aber schon zur Übersetzung in das Übersetzungs-Tool importiert ist? Klar, in diesem Fall müsste man bei dem Reimport einen "merge" der Dateien machen. Dieses Problem wäre also mit vertretbarem Aufwand lösbar. Es gibt aber sicher noch Weitere, an die ich im Moment nicht denke...

Warum mache ich diesen Vorschlag?

Naja, da ich mit C-Programmierung im Bereich Betriebssysteme leider ein eher bescheidenes Wissen habe, kann ich ReactOS in diesem Bereich nur schwer unterstützen. Um aber auch meinen Beitrag zu ReactOS zu leisten, könnte ich mir vorstellen so ein Übersetzungs-Tool zu schreiben. Da ich mich mit Java Client/Server-Programmierung und Datenbanken relativ gut auskenne, würde ich es mit einem Java-Applet und einer MySQL-Datenbank realisieren. Ich würde das Ganze aber nur angehen, wenn es eine realistische Chance gibt, dass dieses Projekt (bei entsprechend geglückter Umsetzung) auch tatsächlich genutzt wird und auch von offizieller Seite empfohlen und unterstützt wird. Ich könnte allerdings erst Mitte März 2005 mit der Umsetzung anfangen, da ich im Moment noch mit meinem Studium (Diplomarbeit, Prüfungen) beschäftigt bin.

Daher würde ich euch um folgende Antworten zu diesem Thema bitten:
  • wie seht ihr die Chancen eines solchen Projekts?
  • bietet es überhaupt einen Mehrwert zur bisherigen Vorgehensweise?
  • welche Risiken bestehen bei der technischen Umsetzung?
  • welche Risiken bestehen bei der Akzeptanz der User?
  • welche Alternativen Vorgehensweisen gäbe es?
  • wie wird die Übersetzung in anderen Projekten (wie z.B. KDE für Linux gibt es ja mittlerweile in über 150 Sprachen) gemacht?

Ich habe diesen Vorschlag bewusst erstmal nur im deutschen Forum gepostet. Falls er hier positiven Anklang findet, kann man dann später auch noch im englischen Forum darüber diskutieren. Ich würde in diesem Fall diesen Text mit evtl. Änderungen dorthin übersetzen.

Vielen Dank an alle die sich die Mühe gemacht haben diesen langen Post zu lesen!
e7
Posts: 92
Joined: Thu Dec 09, 2004 8:32 pm
Location: In Bayern ganz oben

Post by e7 »

Ich hab's mir jetzt mal durchgelesen, und ich merk einfach mal was an:
  • Userakzeptanz: Ich persönlich würde so ein Tool nutzen - allerdings sicher nicht als Java-Applet. Java hab ich schon seit einiger Zeit im Browser deaktivert, da es erstens relativ viel Arbeitsspeicher schluckt und vor allem im Internet in 95 % aller Fälle sowieso nur für diese Navigationsbuttons von Frontpage eingesetzt wird - und darauf kann ich verzichten. Außerdem mag ich Java-Applets nicht so wirklich. Mein Vorschlag wäre, was auch besser mit MySQL oder so zusammenpassen würde: PHP. Das gibt dann schöne schlanke Websites mit übersichtlichen Textfeldern, außerdem sollte es von PHP aus einfacher sein, in den Dateien auf Servern rumzupfuschen ;)
  • Beschreibung und Bedeutung - wie willst du das implementieren? Ich hab mir zwar die Dateien noch nicht angesehen, aber dazu müsste jeder String mit einem Kommentar versehen werden, und zwar einheitlich, so dass man das ganze dann auslesen kann... Oder andere Frage: Ist eine Beschreibung überhaupt nötig? Wenn man sich in beispielsweise der Datei printer.sys befindet, genügt das eigentlich an Kontext zum Übersetzen.
  • Naja, und dann fällt mir noch ein, wie das funktionieren soll, wenn zwei Leute gleichzeitig übersetzen wollen...
Das sollte erst mal reichen, muss ja nicht jeder so lange Texte schreiben wie du ;)
blight
Developer
Posts: 35
Joined: Tue Nov 30, 2004 10:34 pm
Location: away

Post by blight »

Last edited by blight on Wed Feb 23, 2005 1:52 pm, edited 1 time in total.
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

Ansich eine gute Idee, welche sich wahrscheinlich nur sehr schwer umsetzen läßt. Ob man mit Java auf den CVS-tree zugreifen kann weiß ich nicht. Mir wäre irgend ein CMS-System auf PHP und MySql Basis lieber -> weniger Resourcen, funktioniert auf jedem Rechner. Ich könnte mir ein Wiki-System auf dem derzeit basierenden Online CVS-System http://cvs.reactos.com/cgi-bin/cvsweb.cgi/ durchaus vorstellen. Eine relative einfache Möglichkeit wäre mit diesem System das editieren von *.rc Dateien zu erlauben und wie bei RosWiki alle Äderungen zu speichern.

Das heißt es müsste nur jemand das bestehende cvsweb (Original von FreeBSD community - http://www.freebsd.org/projects/cvsweb.html ) um eine editier-funktion für *.rc Dateien erweitern (so wie in RosWiki). Vielleicht mit Login-Funktion damit nicht jeder die Dateien ändern kann.

Ansonsten:
Das suchen von Übersetzungsfehlern geht unter WinXP relativ einfach:
Suchen nach "Dateien und Ordnern" -> "Ein Wort oder Begriff innerhalb der Datei" Option anwählen. Es werden fast alle Textdateien im gewählten Ordner durchsucht. (In der Registry kann man noch andere Dateitypen zur Suche hinzufügen!)
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de »

e7 wrote:Das sollte erst mal reichen, muss ja nicht jeder so lange Texte schreiben wie du ;)
Sorry, hab das nach ner Weihnachtsfeier (viel Alkohol) geschrieben ;)

Sicher man kann natürlich auch PHP statt Java verwenden.

Ich hab mir mittlerweile mal bei anderen Projekten (GNOME, KDE, OpenOffice) die Übersetzungspraxis angeschaut. Meistens werden auch direkt die Sourcen aus dem CVS gezogen und bearbeitet. Zum Teil gibt es aber auch spezielle Tools für die Übersetzung. Die funktionieren aber nur loakal auf dem Rechner, scheinen noch nicht ganz ausgereift zu sein und funktionieren nur für das jeweilige Projekt (Bei OpenOffice sind die Strings für die verschiedenen Sprachen alle in einem File und nicht auf verschiedene verteilt http://l10n.openoffice.org/textattr.src.txt).
Das Gnome Projekt will in Zukunft auch leistungsfähigere Tools für die Übersetzung etwickeln.
Ich werde mir auf jedenfall mal weitere Gedanken machen...
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de »

Also ich hab mir jetzt mal beim KDE-Projekt die Struktur, die für die Übersetzung wichtig ist, näher angeschaut.
Aufbau der internationalization-files im KDE-Projekt:
  • Die Standart/Template Files (in Englisch) haben die extention .pot und sind im Verzeichnis kde-i18n/templates/ gespeichert
  • Alle abgeleiteten Sprachen werden dann jeweils in .po-files gepeichert. Diese Files sind dann in den Verzeichnissen: kde-i18n/$LANG/messages/(package-name)/. Ein Beispiel für ein deutsches File wäre z.B.: kde-i18n/de/messages/kdebase/konqueror.po
  • Die sprach-spezifischen Dokumentations-Files liegen im Verzeichnis: kde-i18n/$LANG/docs/(package-name)/(appfolder)/index.docbook. Beispiel: kde-i18n/de/docs/kdeutils/kdiff/index.docbook
Eine .po/.pot-Datei ist dann aus einem Header und den Inhalten aufgebaut:
Header:

Code: Select all

msgid ""
msgstr ""
"POT-Creation-Date: 2000-02-17 00:58+0100\n"
"PO-Revision-Date: 2000-02-17 08:43+MET\n"
"Last-Translator: Thomas Diehl <thd@kde.org>\n"
"Language-Team: Deutsch <kde-i18n-de@kde.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 0.4\n"
Das "leere" msgid und msgstr ist notwendig, dass es keinen kompilier-Fehler gibt.

Danach folgen dann die eigentlichen Inhalte zum Übersetzen.
Ein Template (.pot):

Code: Select all

#: kedit.cpp:90 kedit.cpp:1071
msgid "Show &Status Bar"
msgstr ""
wird dann z.B. in ein deutsches .po-file übersetzt:

Code: Select all

#: kedit.cpp:90 kedit.cpp:1071
msgid "Show &Status Bar"
msgstr "&Statusleiste anzeigen"
Mit dem Zeichen '#' kann man dann auch noch Fehler in der Übersetzung (#, fuzzy), Änderung der Referenz im C-Source-Code (#, c-format) und Kommenatare (#~) festlegen.
Hier zum Beispiel mal ein Auszug aus einer Datei aus dem KDE.Projekt:

Code: Select all

# Ãœbersetzung von amor.po ins Deutsche
# Thomas Diehl <thd@kde.org>, 2002, 2004.
msgid ""
msgstr ""
"Project-Id-Version: amor\n"
"POT-Creation-Date: 2004-10-12 01:17+0200\n"
"PO-Revision-Date: 2004-08-02 08:59+0200\n"
"Last-Translator: Thomas Diehl <thd@kde.org>\n"
"Language-Team: Deutsch <kde-i18n-de@kde.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.3.1\n"

#: tips.cpp:2
msgid "Don't run with scissors."
msgstr "Messer, Nadel, Schere, Licht sind für kleine Kinder nicht."

#: tips.cpp:5
msgid "Never trust car salesmen or politicians."
msgstr "Trau weder Autoverkäufern noch Politikern."

#: tips.cpp:8
msgid ""
"Real programmers don't comment their code. It was hard to write, it should "
"be hard to understand."
msgstr ""
"Richtige Programmierer kommentieren ihren Code nicht. Es war schwer, ihn zu "
"schreiben. Also sollte es auch schwer sein, ihn zu verstehen."

#: tips.cpp:11
msgid ""
"It is much easier to suggest solutions when you know nothing about the "
"problem."
msgstr ""
"Es ist wesentlich einfacher Lösungen für etwas vorzuschlagen, wenn man "
"nichts über das Problem weiß."

#: tips.cpp:14
msgid "You can never have too much memory or disk space."
msgstr "Man kann nie genug Speicher oder Platz auf der Festplatte haben."

#: tips.cpp:17
msgid "The answer is 42."
msgstr "Die Antwort lautet \"42\"."

....
Den Aufbau der Dateien und Verzeichnisse im KDE-Projekt würde ich als vorbildlich bezeichnen und macht es natürlich auch sehr einfach ein Tool zu entwerfen das die Übersetzung erleichtert. Das Einlesen/Parsen der Dateien ist damit doch sehr leicht im Gegensatz zu der Struktur im ReactOS-Projekt.
Eine Datei sieht hier wie folgt aus:

Code: Select all

LANGUAGE LANG_GERMAN, SUBLANG_DEFAULT

STRINGTABLE DISCARDABLE
{
     IDS_CLOSE    "Schließen"
}

STRINGTABLE DISCARDABLE
{
     IDM_TODAY    "Heute:"
     IDM_GOTODAY  "Gehe zu Heute"
}

STRINGTABLE DISCARDABLE
{
    IDS_SEPARATOR "Trennzeichen"
}

STRINGTABLE DISCARDABLE
{
    HKY_NONE "Keiner"
}

IDD_PROPSHEET DIALOG DISCARDABLE 0, 0, 220, 140
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_VISIBLE
CAPTION "Eigenschaften für "
FONT 8, "MS Sans Serif"
BEGIN
  DEFPUSHBUTTON "&OK",        IDOK,4,122,50,14, WS_TABSTOP | WS_GROUP
  PUSHBUTTON    "A&bbrechen", IDCANCEL,58,122,50,14
  PUSHBUTTON    "&Anwenden",  IDC_APPLY_BUTTON,112,122,50,14,WS_DISABLED
  PUSHBUTTON    "&Hilfe",     IDHELP,166,122,50,14,WS_TABSTOP|WS_GROUP
  CONTROL       "Tab",        IDC_TABCONTROL,"SysTabControl32",WS_CLIPSIBLINGS|WS_GROUP|WS_TABSTOP|TCS_MULTILINE,4,4,212,114
END


IDD_WIZARD DIALOG DISCARDABLE 0, 0, 290, 159
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_VISIBLE
CAPTION "Wizard"
FONT 8, "MS Sans Serif"
BEGIN
  DEFPUSHBUTTON "&Beenden",   IDC_FINISH_BUTTON,121,138,50,14
  DEFPUSHBUTTON "&Weiter >", IDC_NEXT_BUTTON,121,138,50,14
  PUSHBUTTON    "< &Zurück", IDC_BACK_BUTTON,71,138,50,14
  PUSHBUTTON    "Abbrechen", IDCANCEL,178,138,50,14
  PUSHBUTTON    "&Hilfe",     IDHELP,235,138,50,14,WS_GROUP
  LTEXT         "",          IDC_SUNKEN_LINE,7,129,278,1,SS_SUNKEN
  CONTROL       "Tab",       IDC_TABCONTROL,"SysTabControl32",WS_CLIPSIBLINGS | WS_DISABLED,7,7,258,5
  LTEXT	        "",        IDC_SUNKEN_LINEHEADER,0,35,290,1,SS_LEFT | SS_SUNKEN | WS_CHILD | WS_VISIBLE
END


IDD_TBCUSTOMIZE DIALOG DISCARDABLE 10, 20, 357, 125
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "Toolbar einrichten"
FONT 8, "MS Sans Serif"
BEGIN
  DEFPUSHBUTTON "&Schließen",               IDCANCEL,308,6,44,14
  PUSHBUTTON    "&Zurücksetzen",            IDC_RESET_BTN,308,23,44,14
  PUSHBUTTON    "&Hilfe",                   IDC_HELP_BTN,308,40,44,14
  PUSHBUTTON    "Nach &Oben verschieben",   IDC_MOVEUP_BTN,308,74,44,14
  PUSHBUTTON    "Nach &Unten verschieben",  IDC_MOVEDN_BTN,308,91,44,14
  LTEXT         "&Vorhandene Knöpfe:", -1,4,5,84,10
  LISTBOX       IDC_AVAILBTN_LBOX,4,17,120,100, LBS_NOTIFY | LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP
  PUSHBUTTON    "H&inzufügen ->",           IDOK, 131, 42, 44, 14
  PUSHBUTTON    "<- &Löschen",              IDC_REMOVE_BTN,131,62,44,14
  LTEXT         "&Toolbarknöpfe:", -1,182,5,78,10
  LISTBOX       IDC_TOOLBARBTN_LBOX, 182,17,120,100,LBS_NOTIFY | LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP
END
Hier sind noch zusätzliche Informationen wie Schrift-Art/Größe und Informationen über Dialog-Oberflächen (Größe/Position) enthalten. Das macht das parsen natürlich wesentlich schwieriger. Außerdem sind die .rc-Dateien nicht alle an einem Ort im Verzeichnisbaum konzentriert. Ich glaube aber nicht das ihr die Informationen nochmal weiter kapseln wollt, wie es beim z.B. beim KDE-Projekt ist. Oder gibt es da doch noch Pläne?
Wollt das nur mal so mitteilen. Werde weiter an dem Thema dran bleiben...
NetSlayer
Posts: 36
Joined: Sun Dec 05, 2004 8:55 pm
Contact:

Post by NetSlayer »

Das was du da bei KDE beschreibst ist das GNU gettext-Programm. Dadurch wird den Projekten die Arbeit bei der Übersetzung ziemlich weit abgenommen.

Das kommt aber für ReactOS nicht in Frage, da man erst gettext-Libraries schreiben müsste.
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de »

Wie genau funktioniert das dann? Wird das ganze mit gettext trotzdem erst kompiliert oder werden die Texte zur Laufzeit eingebunden? Was genau ist das Problem mit den gettext-Libraries? Klar ist das es einingen Aufwand bedeuten würde. Kann man da aber nicht einigen Code vom KDE/Gnome - Projekt als Grundlage benutzen? Du sagst ja selbst das die Arbeit mit der Übersetzung dann ziemlich vereinfacht wird. Würde es sich nicht lohnen sowas auch für ReactOS einzuführen? Oder geht das technisch nicht oder gibt es sonstige Probleme, wie zum Beispiel Performance?
NetSlayer
Posts: 36
Joined: Sun Dec 05, 2004 8:55 pm
Contact:

Post by NetSlayer »

ma-games.de wrote:Wie genau funktioniert das dann? Wird das ganze mit gettext trotzdem erst kompiliert oder werden die Texte zur Laufzeit eingebunden? Was genau ist das Problem mit den gettext-Libraries? Klar ist das es einingen Aufwand bedeuten würde. Kann man da aber nicht einigen Code vom KDE/Gnome - Projekt als Grundlage benutzen? Du sagst ja selbst das die Arbeit mit der Übersetzung dann ziemlich vereinfacht wird. Würde es sich nicht lohnen sowas auch für ReactOS einzuführen? Oder geht das technisch nicht oder gibt es sonstige Probleme, wie zum Beispiel Performance?
Lies mal diesen Forenpost.

Problem ist, dass man das meines Wissens nach nicht in einem Betriebssystem einsetzen kann, da es selbst auf einem solchen laufen soll. Es ist für Linux-Programme gedacht.
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de »

Vielen Dank! Ich hab mir das mal durchgelesen. Allerdings nur den Post und nicht das gettext manual. Es kann schon sein, das gettext erst dann funktioniert wenn das "Grundbetriebssystem" läuft. Aber ab "dann" müsste es prinzipiell einsetzbar sein. Und der meiste Teil von ReactOS, bei dem Übersetzungen vorgenommen werden müssen, wird sich erst "danach" abspielen denke ich. Es gibt ja auch schon vier verschiedene GPL gettext Implementierungen für win32.
Aber das ganze muss ja nicht unbedingt mir gettext aufgezogen werden. Mir scheint es halt im Moment in ReactOS nicht 100%ig gut gelöst zu sein. Aber mir fehlen die Hintergründe, um das genau zu beurteilen und richtige Lösungen vorzuschlagen. Allerdings wäre eine weitere Trennung der Daten für das ReactOS-Projekt für die Zukunft auf jeden Fall von Vorteil. Vielleicht kann sich ja nochmal der ein oder andere Entwickler zu Wort melden und seine Sicht der Dinge hier schreiben.
Für ein Übersetzungstool würde es aber immense Vorteile bringen, dass ganze ähnlich der Struktur von KDE/Gnome anzupassen!
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de »

Ich hab mich mal beim AROS OS, also einem richtigen OS-Projekt, bezüglich internationalization umgeschaut. Ich weiß zwar nicht welcher Mechanismus dahinter steckt, aber der Aufbau der language-files ist perfekt und ähnlich wie bei KDE/Gnome. Leider sind aber auch in diesem Projekt die language-files nicht in einem bestimmten Verzeichnis, sondern über den ganzen Source-Tree verteilt. Aber der Aufbau der Files ansich ist wirklich super: Es sind nur die String-ID und die übersetzten Strings darin.
Hier z.B die Datei deutsch.ct:

Code: Select all

## version $VER: localeprefs.catalog 1.0 (23.02.2001)
## codeset 0
## language deutsch
;
MSG_CANT_OPEN_LIB
Kann %s V%ld nicht öffnen!\n
;
MSG_CANT_LOCK_SCR
Kann public Screen nicht locken!
;
MSG_CANT_GET_DRI
Kann DrawInfo nicht ermitteln!
;
MSG_CANT_GET_VI
Kann VisualInfo nicht ermitteln!
;
MSG_CANT_CREATE_GADGET
Kann Gadgets nicht erzeugen!
;
MSG_CANT_CREATE_MENUS
Kann Menus nicht erzeugen!
;
MSG_CANT_CREATE_WIN
Kann Fenster nicht erzeugen!
;
MSG_WINTITLE
Landes-Voreinsteller (Locale)
;
MSG_MEN_PROJECT
Projekt
;
MSG_MEN_PROJECT_OPEN
O\0Öffnen ...
;
MSG_MEN_PROJECT_SAVEAS
A\0Speichern als ...
;
MSG_MEN_PROJECT_QUIT
Q\0Beenden
;
MSG_MEN_EDIT
Vorgaben
;
MSG_MEN_EDIT_DEFAULT
D\0Auf Vorgaben zurücksetzen
;
MSG_MEN_EDIT_LASTSAVED
L\0Auf zuletzt gespeichertes
;
MSG_MEN_EDIT_RESTORE
R\0Auf vorherigen Stand
;
MSG_MEN_SETTINGS
Einstellungen
;
MSG_MEN_SETTINGS_CREATEICONS
I\0Piktogramme erzeugen?
;
MSG_ASL_OPEN_TITLE
Laden Locale-Vorgaben
;
MSG_ASL_SAVE_TITLE
Speichern Locale-Vorgaben
;
MSG_OK
Ok
;
MSG_GAD_AVAIL_LANGUAGES
Verfügbare Sprachen
;
MSG_GAD_PREF_LANGUAGES
Bevorzugte Sprachen
;
MSG_GAD_CLEAR_LANGUAGES
Sprachen löschen
;
MSG_GAD_SAVE
Speichern
;
MSG_GAD_USE
Benutzen
;
MSG_GAD_CANCEL
Abbrechen
;
MSG_GAD_TAB_LANGUAGE
Sprache
;
MSG_GAD_TAB_COUNTRY
Land
;
MSG_GAD_TAB_TIMEZONE
Zeitzone
;
MSG_TIMEZONE_1HOUR
Zeitzone: 1 Stunde auf GMT
;
MSG_TIMEZONE_HOURS
Zeitzone: %ld Stunden auf GMT
;
MSG_TIMEZONE_HOURSMINS
Zeitzone: %ld Stunden %ld Minuten auf GMT
;
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

Die .rc Dateien sind einfach Dateien, die der Kompiler lesen kann. Wenn man etwas anderes haben will bräuchte jeder der ReactOs kompilieren will ein bestimmtes Tool.
Where do you want ReactOS to go today ?
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de »

Die .ct -Datei aus dem AROS-Projekt kann aber anscheinend auch vom Compiler gelesen werden. Ich glaube nicht das die Texte erst zur Laufzeit eingebunden werden. Diesen Performance-Nachteil wird wohl niemand hinnehmen wollen.
Aber ich hab nun endlich die Translation-Team-Mailing-List gefunden. :oops:
Werd dort mal mein Anliegen posten...
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

ma-games.de wrote:Die .ct -Datei aus dem AROS-Projekt kann aber anscheinend auch vom Compiler gelesen werden.
Fragt sich nur von welchem.
Where do you want ReactOS to go today ?
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de »

Von der AROS Website:
The following software is required for compiling AROS:

* GCC 3.2.2+
* GNU Binutils
* GNU Make
* GNU AWK (GAWK) - other awks may also be suitable
* Python 2.2.1+
* Bison
* pngtopnm and ppmtoilbm (part of the netpbm package)
* Autoconf
* Automake
* Common utilities like cp, mv, sort, uniq, head, ...
Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests