Topic: [Patch] Sprache Deutsch unter Ubuntu

11 — 20 of 27 Posts ‹‹ previous 1 2 3 next ››

martin Joined: 2011-01-13, 14:21 Posts: 65 Likes to be here	Posted at: 2011-01-29, 21:53 Hey, ich glaub Nasenbaer hat Recht! Ich hab soeben mal sämtliche meiner mittels $ locale -a ausgegebenen Locale-Deskriptoren ausprobiert. Und scheinbar funktionieren unter Ubuntu auch "de_AT.utf8", "de_BE.utf8", "de_CH.utf8", "de_DE.utf8", "de_LI.utf8" und "de_LU.utf8". Auch die Gegenprobe habe ich gemacht: "de_GB.utf8" funktioniert erwartungsgemäß nicht. Jetzt müssen wir nur noch die Ausgabe von $ locale -a ins Programm einlesen und dann haben wir so etwas wie eine Lookup-Tabelle - von der ich schonmal geschrieben habe - mit der dann (entsprechende Vorverarbeitung vorausgesetzt) ein Aktivieren der systemunabhängig richtigen Locale ermöglicht wird. Ich denke, wir sind auf einem guten Weg! Viele Grüße Martin Übrigens: Ich schlage vor, nur die auf dem System installierten Locales als Sprachen in Widelands auswählbar zu machen (plus Englisch natürlich) und/oder einen Hinweis in den Optionen zu ergänzen, dass das Betriebssystem die gewählte Sprache auch unterstützen muss. Das erspart bestimmt ein paar Fragen verwirrter Nutzer... Top Quote

carli Topic Opener Joined: 2010-12-31, 16:53 Posts: 39 Pry about Widelands	Posted at: 2011-01-30, 14:31 Jetzt müssen wir nur noch die Ausgabe von $ locale -a ins Programm einlesen und dann haben wir so etwas wie eine Lookup-Tabelle - von der ich schonmal geschrieben habe - mit der dann (entsprechende Vorverarbeitung vorausgesetzt) ein Aktivieren der systemunabhängig richtigen Locale ermöglicht wird. btw: macht man das in C++/boost immer noch mit popen()? Oder hat Boost eine Process-Klasse mit Stream-Komponenten? Nasenbaer: wie sieht da der Codestyle aus? Top Quote

SirVer Joined: 2009-02-19, 15:18 Posts: 1440 One Elder of Players Location: Germany - Munich	Posted at: 2011-01-30, 15:27 Die Ausgabe von locale -a zu parsen ist eine schlechte Idee. Ich würde eher vorschlagen mal in den Sourceode des Programmes locale zu spicken und rauszufinden, wie der "offizielle" weg ist an die Liste von installierten locals zu kommen. output von anderen Programmen zu parsen ist immer fehleranfällig und potentiell gefährlich. Top Quote

martin Joined: 2011-01-13, 14:21 Posts: 65 Likes to be here	Posted at: 2011-01-31, 07:27 SirVer schrieb: Ich würde eher vorschlagen mal in den Sourceode des Programmes locale zu spicken und rauszufinden, wie der "offizielle" weg ist an die Liste von installierten locals zu kommen. Das ist natürlich auch eine Idee - wahrscheinlich sogar besser und eleganter :) Das würde uns bestimmt die Verwendung von popen() und ähnlichem Zeug ersparen. Da hab ich gar nicht dran gedacht... output von anderen Programmen zu parsen ist immer fehleranfällig und potentiell gefährlich. Stimmt - das hab ich auch schon erlebt! Als der NetworkManager unter Ubuntu/Debian noch nicht existierte bzw. ausgereift war, hatte ich mir ein Skript geschrieben, um mich komfortabel mit WLAN-Hotspots verbinden zu können. Das basierte dummerweise auf der Ausgabe von $ iwlist wlan0 scan - und diese Ausgabe sah in jeder Folgeversion ein Bisschen anders aus und ich musste das Skript deshalb jedes Mal anpassen Also: stürzen wir uns auf den locale-source! Viele Grüße Martin Top Quote

SirVer Joined: 2009-02-19, 15:18 Posts: 1440 One Elder of Players Location: Germany - Munich	Posted at: 2011-01-31, 07:40 Euer enthusiasmus ist sehr erfrischen! Wäre super, wenn dieses blöde locals Problem entgültig gelöst werden könnte; das begleitet uns schon zu viele builds. Top Quote

martin Joined: 2011-01-13, 14:21 Posts: 65 Likes to be here	Posted at: 2011-02-02, 16:04 Hallo zusammen, Ich hab den Source von locale aus der eglibc durchgeschaut und hoffe, dass wir irgendwelche Übereinstimmungen zwischen den Distributionen finden können... Folgende Erkenntnisse: locale -a generiert seine Liste einerseits aus dem Locale-Archiv in LOCALEDIR/locale-archive und andererseits aus LOCALEDIR//LC_IDENTIFICATION - Ubuntu nutzt offensichtlich nur das Archiv. LOCALEDIR* wird laut configure über das Makefile von eglibc standardmäßig auf /usr/local/share/locale gesetzt. Unter Ubuntu allerdings /usr/lib/locale. locale-archive ist eine Binärdatei mit definiertem Format, sie ließe sich daher auslesen - wenn man denn wüsste, wo genau sie sich bei jeder Distro befindet. Allerdings ist sie bei mir über 8 MB groß! Es gibt eine Umgebungsvariable LOCPATH, mit der man ein anderes Verzeichnis für den Locale-Pfad angeben kann. Diese Variable wird aber nicht einheitlich über die Distributionen hinweg verwendet. In man 1 locale wird sie nur bei Debian/Ubuntu erwähnt. Dort wird dann auch gesagt, dass /usr/lib/locale verwendet wird, falls LOCPATH nicht gesetzt ist. Bei Ubuntu gibt es zudem eine Datei /var/lib/belocs/list, deren Inhalt exakt(!) mit der Ausgabe von locale -a übereinstimmt. Es existiert weiterhin eine Datei /var/lib/locales/supported.d/local, welche die auf dem System tatsächlich installierten Locales benennt. Da ich nur Deutsch und Englisch installiert habe, sieht die Datei bei mir folgendermaßen aus: `de_DE.UTF-8 UTF-8 en_US.UTF-8 UTF-8` So. Ich wünschte, die Auswertung hätte Eindeutigeres zu Tage gefördert. Die Frage an euch nun: Seht ihr verwertbare Übereinstimmungen zu anderen Distributionen? Anderenfalls plädiere ich wieder für die Auswertung des Programmoutputs von locale -a - obwohl es nicht die schönste Lösung ist - aber zumindest scheint diese Ausgabe POSIX-genormt zu sein... Viele Grüße Martin Top Quote

SirVer Joined: 2009-02-19, 15:18 Posts: 1440 One Elder of Players Location: Germany - Munich	Posted at: 2011-02-02, 20:30 Danke für deine Untersuchungen! Dennoch: Ich raff das einfach nicht. Wie machen das denn andere Spiele? Zum Beispiel Wesnoth muss dieses Problem doch auch irgendwie gehabt und gelöst haben. Magst Du da nicht auch noch mal stöbern. Das parsen von consolen output sollte die letze lösung sein, wenn uns wirklich nix mehr einfällt. Top Quote

Nasenbaer Joined: 2009-02-21, 18:17 Posts: 826 One Elder of Players Location: Germany	Posted at: 2011-02-02, 23:26 Moin, ich hab mich auch noch mal umgeschaut. Besonders interessant scheint mir /usr/include/locale.h - hierrin befindet sich nicht nur die setlocale() Funktion, die in i18n.cc bereits verwendet wird, sondern unter anderem auch: /* Return a duplicate of the set of locale in DATASET. All usage counters are increased if necessary. / extern __locale_t duplocale (__locale_t __dataset) __THROW; / Free the data associated with a locale dataset previously returned by a call to `setlocale_r'. / extern void freelocale (__locale_t __dataset) __THROW; / Switch the current thread's locale to DATASET. If DATASET is null, instead just return the current setting. The special value LC_GLOBAL_LOCALE is the initial setting for all threads and can also be installed any time, meaning the thread uses the global settings controlled by `setlocale'. / extern __locale_t uselocale (__locale_t __dataset) __THROW; / This value can be passed to `uselocale' and may be returned by it. Passing this value to any other function has undefined behavior. */ # define LC_GLOBAL_LOCALE ((__locale_t) -1L) ich konnte das bisher mangels Zeit leider nicht weiter testen, aber von den Kommentaren könnte uns das eventuell weiterhelfen. Liebe Grüße Peter Top Quote

martin Joined: 2011-01-13, 14:21 Posts: 65 Likes to be here	Posted at: 2011-02-03, 17:18 Danke an SirVer, für den Hinweis mit Wesnoth. Ich werd ab sofort stattdessen dort mitmachen Nee - kleiner Scherz. Widelands ist dem nicht nur in Bezug auf die Grafik meilenweit voraus, sondern - da ich nicht so der Fantasy-Fan bin - trifft Widelands auch meinen Computerspielegeschmack sehr viel besser. Also an dieser Stelle nochmal ein großes Lob an das Widelands-Team! Der Wesnoth-Source gibt allerdings einige aufschlussreiche Details preis - hier meine Erkenntnisse: Wesnoth verwendet ebenfalls Gettext. Das ist schonmal gut, denn sonst hätte die Recherche nix gebracht. Wesnoth macht deutlich mehr Anstrengungen (gemessen an der Quelltext-Länge), die Locale richtig zu setzen. "Viel hilft viel" würde ich allerdings nicht sagen - man kann es für unsere Situation ein Bisschen zusammenkürzen. Wesnoth scheint an dieser Stelle relativ sauber programmiert zu sein. Viele, z.T. selbsterklärende Funktionen; Programmcode und Locale-Daten sind gut voneinander getrennt. Für jede unterstützte Sprache existiert eine eigene Config-Datei, die nicht nur die Locale festlegt, sondern auch die im Notfall zu verwendenden Alternativ-Locales benennt. Für de_DE werden als Alternativen de_LI, de_LU, de_CH und de_AT angegeben. Die wahrscheinlich wichtigste Erkenntnis: Wesnoth prüft das Ergebnis von setlocale ab. Das tun wir derzeit nicht! Basierend auf dem vorhergehenden Punkt werden somit die Locale und ihre Alternativen sowie drei verschiedene Encodings (".utf-8", ".UTF-8", "") sukzessive durchprobiert - solange bis setlocale im Erfolgsfall einen von NULL verschiedenen Wert zurückgibt. Das Ganze wird nur mit LC_MESSAGES durchprobiert. Wenn es funktioniert, werden auch LC_NUMERIC und LC_ALL auf diese Locale gesetzt. Auf meinem System würden von Wesnoth also nacheinander de_DE.utf-8, de_DE.UTF-8 und de_DE durchprobiert. Bereits erstere würde funktionieren. Eine Locale namens "de" wird übrigens nicht verwendet. Ein eventuelles "\@euro" wird außerdem vorher abgetrennt und entsprechend POSIX hinter dem Encoding wieder angefügt. Vorher wird noch die Umgebungsvariable LANGUAGE entleert - wahrscheinlich, um Nebenwirkungen mit dieser Variable zu vermeiden. Mit LANG wird hingegen nur unter Beos, Apple und Windows hantiert, nicht aber unter Linux. Zum Programmstart wird die LC_ALL auf "English" (Windows) bzw auf "C" (sonst) gesetzt und in letzterem Fall LC_MESSAGES über "" angepasst. Damit ist ein einheitlicher Ausgangspunkt geschaffen. Die Sprachauswahlliste wird aus "System default language" und den Sprachbezeichnungen aus jeder Sprach-Config-Datei zusammengebastelt. Wird die aktuelle Locale nicht in der Liste gefunden, wird die Systemsprache verwendet. Wesnoth liest an keiner Stelle alle verfügbaren Locales aus und Widelands hat das wahrscheinlich auch nicht nötig. Eher sind die längeren Locale-Bezeichner mit der Erweiterungsmöglichkeit um ".utf-8" etc. und ein sinnvolles Durchprobieren der Schlüssel zum Erfolg. Ich denke, am wichtigsten wird für uns erstmal das Abprüfen des setlocale-Ergebnisses und eine damit verbundene "Probierschleife" sein. Davon ausgehend müssen wir wahrscheinlich die Sprachkonfigurationsdatei nochmal überarbeiten. Kein geringer Aufwand, aber hey - es sieht so aus, als könnte es funktionieren Viele Grüße Martin Edited: 2011-02-03, 17:19 Top Quote

SirVer Joined: 2009-02-19, 15:18 Posts: 1440 One Elder of Players Location: Germany - Munich	Posted at: 2011-02-04, 10:33 Das klingt doch super. Klau so viel wie Du kannst von Wenoth (via Copy & Paste); das ist auch GPL und damit ist das kein Problem. Erwähne natürlich woher die Lösung kommt. Das scheint mir ein vielversprechender Ansatz! Gute Arbeit. lg, Holger Top Quote

‹‹ previous 1 2 3 next ››