pygettext oder xgettext?

[pot]

Morgähn..

Wenn ich versuche ein Programm mittels sys.exit(_('string')) abzubrechen, dessen String bei der übersetzten Version ein Umlaut enthält, bekomme ich Fehlermeldungen. Allerdings nur dann, wenn ich xgettext benutze um .pot-Dateien zu erstellen. Benutze ich pygettext (was ja veraltet sein soll), funktioniert es einwandfrei.

Am liebsten würde ich deswegen pygettext verwenden, da es einwandfrei funktionierte. Doch warum sollte ich veraltete Software einsetzen? Hat jemand eine Idee dazu?

Ausserdem: Gibt es ein vim-Plugin um vorhandene .po-Dateien mit neueren .pot-Dateien zu aktualisieren? Dabei möchte ich nicht auf externe Programme wie poEdit zugreifen. Ich hab da mal ein Plugin gefunden, ist aber, denke ich, nicht das, was ich suche.

Code: Alles auswählen

#: ../../src/mathpyx_console.py:390
msgid "Please specify a command"
msgstr "Bitte wählen Sie ein Kommando"

Code: Alles auswählen

Traceback (most recent call last):
  File "/usr/bin/mathpyx", line 414, in <module>
    ConsoleInterface().start()
  File "/usr/bin/mathpyx", line 408, in start
    (options, args) = self._parse_args()
  File "/usr/bin/mathpyx", line 390, in _parse_args
    parser.error(_('Please specify a command'))
  File "/usr/lib/python2.5/site-packages/mathpyx/cmdoptparse.py", line 184, in error
    'message': msg})
  File "/usr/lib/python2.5/optparse.py", line 1551, in exit
    sys.stderr.write(msg)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 24: ordinal not in range(128)

"parser.error(_('Please specify a command'))"
parser ist ein Objekt. error() eine Methode, die wiederrum sys.exit ausführt.

Alle anderen Umlaute funktionieren sonst. Any ideas?

Grüsse
Pot

[gerold]

Benutze ich pygettext (was ja veraltet sein soll), funktioniert es einwandfrei.

Hallo Pot!

pygettext ist **die Wahl** für Python. Wo steht denn, dass es veraltet sein soll? Das habe ich ja noch nie gehört.

mfg
Gerold

[pot]

In der manpage:

Code: Alles auswählen

[...]pygettext is deprecated. The current version of xgettext supports many languages, including Python[...]

Ich hätte zwar eine Lösung, nämlich einige Funktionen des modifizierten encodinghelpers von Sebastian Wiesner (lunar hier im Forum) zu benutzen. Allerdings verstehe ich den Aufwand nicht, den man für einen simplen Befehl wie sys.exit() braucht, wo print() doch so wunderbar funktioniert.

edit oh.. bist du der Autor von Encodinghelper?

Grüsse
Pot

[Leonidas]

Hint: Unicode-Strings nutzen. ugettext() nutzen. Magisches Encoding-Cookie auf UTF-8 setzen.

[pot]

Hint: Unicode-Strings nutzen.

Was meinst du damit?

ugettext() nutzen. Magisches Encoding-Cookie auf UTF-8 setzen.

Alles schon getan.

Grüsse
Pot

[veers]

Poste mal die Ausgaben von:
file spam.po
und locale

Zum aktualisieren nimm doch einfach msgmerge

[pot]

Poste mal die Ausgaben von:
file spam.po
und locale

Code: Alles auswählen

remo@remuntu:~/Programmierung/Projekte/mathpyx/trunk/po/mathpyx$ file de.po 
de.po: UTF-8 Unicode English text
remo@remuntu:~/Programmierung/Projekte/mathpyx/trunk/po/mathpyx$ locale
LANG=de_CH.UTF-8
LC_CTYPE="de_CH.UTF-8"
LC_NUMERIC="de_CH.UTF-8"
LC_TIME="de_CH.UTF-8"
LC_COLLATE="de_CH.UTF-8"
LC_MONETARY="de_CH.UTF-8"
LC_MESSAGES="de_CH.UTF-8"
LC_PAPER="de_CH.UTF-8"
LC_NAME="de_CH.UTF-8"
LC_ADDRESS="de_CH.UTF-8"
LC_TELEPHONE="de_CH.UTF-8"
LC_MEASUREMENT="de_CH.UTF-8"
LC_IDENTIFICATION="de_CH.UTF-8"
LC_ALL=

Zum aktualisieren nimm doch einfach msgmerge

Oh cool, danke für den Tipp.

Wo es keine exakte Übereinstimmung bei Meldungen gibt, wird mittels nicht-exakter Suche versucht, ein besseres Ergebnis zu erzielen.

Werden diese unexakten, automatischen "Übersetzungen" auch irgendwie markiert, damit vim bspw. diese hervorheben kann (so à la poEdit)?

edit
Okay, habs ausprobiert, es wird das Label "fuzzy" angebracht. Mit ensprechenden Plugins kann man in vim auch danach suchen.

Grüsse
Pot

[Leonidas]

Hint: Unicode-Strings nutzen.

Was meinst du damit?

Code: Alles auswählen

# -*- coding: UTF-8 -*-
text = u"Das ist ein Unicode-String"

Damit wird der String beim laden UTF-8 dekodiert und hat im Skript nun den Typ `unicode`.

[pot]

Hint: Unicode-Strings nutzen.

Was meinst du damit?

Code: Alles auswählen

# -*- coding: UTF-8 -*-
text = u"Das ist ein Unicode-String"

Damit wird der String beim laden UTF-8 dekodiert und hat im Skript nun den Typ `unicode`.

Vor _jeden_ String ein u anhängen? Ist das denn nötig, bzw kann man das nicht einmal global definieren?

Grüsse
Pot

[veers]

Ja, nein kann man nicht, wird aber Python 3 der Standard String Typ sein,

[Leonidas]

Ja, nein kann man nicht, wird aber Python 3 der Standard String Typ sein,

Es wird sozusagen vertauscht. Dann gibt es Bytestrings nur noch mit b-Literal davor. Finde ich super, damit schließt Python zu Java auf und hoffentlich werden nun alle lernen, dass an Unicode kein Weg vorbei führt.

[pot]

Das find ich ehrlich gesagt beschissen. Für was gibt man denn dieses "magic cookie" an und kodiert seine Scripte korrekt?

Grüsse
Pot

[veers]

Das find ich ehrlich gesagt beschissen. Für was gibt man denn dieses "magic cookie" an und kodiert seine Scripte korrekt?

Grüsse
Pot

Dafür das danach ein Byte auf einmal 4 Bytes lang ist und nichts mehr funktioniert?

[Leonidas]

Dafür das danach ein Byte auf einmal 4 Bytes lang ist und nichts mehr funktioniert?

Wenn nichts mehr funktioniert, dann hat man was falsch gemacht und sollte so früh wie möglich auf die Nase fallen. Spätestens dann sollte man sich wirklich mal klar machen, was Bytestrings sind, was Unicodestrings sind und was Encodings sind. Ansonsten funktionieren Umlaute, wenn dann nur zufällig und unter bestimmten Vorraussetzungen.

Wenn man intern mit Unicode arbeitet hat man meist die ganzen Probleme nicht. Und wie lang ein "Byte" ist, hängt auch ab, ob man ein oder UCS2 oder UCS4-Python hat.

Ein Magic-Cookie sieht so aus:

Code: Alles auswählen

# -*- coding: UTF-8 -*-

Das ist der Emacs-Stil des Cookies, es gibt aber auch den Vi-Stil fürs Cookie, nur wird der von kaum jemandem benutzt, also in der Regel auch nicht von vim-Usern. Wie du siehst ist dieses Cookie ein Kommentar, er wird in der Regel in die zweite Zeile geschrieben, nach der Shebang.

[pot]

Code: Alles auswählen

# -*- coding: UTF-8 -*-

Das ist der Emacs-Stil des Cookies, es gibt aber auch den Vi-Stil fürs Cookie, nur wird der von kaum jemandem benutzt, also in der Regel auch nicht von vim-Usern.

Ich denke, das ist so, weil AFAIR in der Style Guide von Python Codes das so beschrieben wird.

Naja, wie gesagt, ich hab mit Hilfe des encodinghelpers das Problem lösen können. Hoffe mal auf bessere Zeiten in python3

Grüsse
Pot

[BlackJack]

Kann man nicht einfach bei Bytestrings im Quelltext bleiben und die auf Englisch und ASCII beschränken und durch Unicodezeichenketten beim Übersetzen ersetzen? Dann sollte es doch eigentlich keine Probleme geben!?

[pot]

Keine Ahnung. Wäre vielleicht ein gescheiter Ansatz, nur müsste jeder Editor das kapieren und ich glaube kaum dass beispielsweise bei einem grossen Projekt, das noch Entwickler mehrerer Betriebsysteme hat, sowas gut möglich ist. Wieso nicht gleich auf UTF-8 setzen?

Grüsse
Pot

[BlackJack]

Was gibt's da gross zu kapieren? Und das standardmässig alle Zeichenketten Unicode sind, ist kein Allheilmittel. Ich höre schon jetzt alle heulen das dann plötzlich Sachen die jetzt ganz einfach sind, dann plötzlich nicht mehr funktionieren ohne das man sich doch mal mit Unicode auseinandersetzt.

[pot]

Krieg dich wieder ein! Ich hab nicht gesagt ich kapiere nix sondern nur, dass ich nicht weiss ob das wirklich eine Lösung sein sollte.

Grüsse
Pot

[Leonidas]

nur müsste jeder Editor das kapieren und ich glaube kaum dass beispielsweise bei einem grossen Projekt, das noch Entwickler mehrerer Betriebsysteme hat, sowas gut möglich ist.

Wenn ein Editor so etwas nicht unterstützt ist er schlich für die Tonne. Sich auf schlechte Tools hinauszureden ist keine gute Idee, wenn es bessere gibt

Aber im ernst: vermutlich wäre es in der Tat sinnvoller die zu Übersetzenden Strings in Englisch zu haben (ob Unicode oder nicht, das bleibt jedem selbst überlassen, aber an der Stelle ist vermutlich so ziemlich egal, weil die später sowieso durch Unicode-Strings ersetzt werden).