Die FHEM-Gemeinde waechst unaufhoerlich (leider?), mit dem Ergebnis, dass auch Leute in Italien FHEM verwenden und auch verkaufen wollen. Das ist per se nicht schlimm, aber sie wollen die Texte auf italienisch sehen, und haben angefangen fhem.pl mit gettext zu versehen, und haben mir eine erste Version geschickt.
Meine erste Euphorie (ahem) hat sich inzwischen noch mehr gelegt, da ich unter OSX das gettext Modul nicht (schnell) uebersetzt kriege, und ich frage mich, wie das andere dann hinkriegen sollen. Ohne dieses Modul faehrt fhem.pl gar nicht hoch.
Was ist denn Eure Meinung zum Thema?
- fhem ist unverkäuflich, da unbezahlbar
- eine Unterstützung in beliebig vielen Sprachen beträfe ja nicht nur fhem.pl sondern jedes einzelne Modul. Eine generische Unterstützung für deutsch und englisch fände ich völlig ausreichend
Internationalization wäre natürlich ganz nett. Darf natürlich nicht zu Lasten von Performance, Bequemlichkeit etc. gehen.
Wäre vielleicht eine statische Lösung gangbar.
So etwas in der Art: In Code stehen Meldungen in Form von Platzhaltern (am besten zusammengefasst an einer (wenigen) Stelle(n)). Bei der ersten Inbetriebnahme wird entweder das ganze Modul mit den Meldungen ersetzt, oder die Texte geparst und durch Texte aus einer Config-Sprach-Datei ersetzt. Eine Art Preprozessor...
Dann müsste für jede Sprache lediglich die (englische) Sprachdatei übersetzt werden. Können Italiener dann selber machen ;)
ZitatEine generische Unterstützung für deutsch und englisch fände ich völlig ausreichend
:) Wenn man keine anderen Sprachen spricht, ist das auch verstaendlich :)
ich spreche durchaus noch ein paar andere Sprachen :)
Was soll denn übersetzt werden?
set meineLampe aus
Grüße
Boris
Naja, etwas mehr ist das schon ;)
Einige Module verwenden "menschenlesbare" Texte.
Ich glaube auch, dass es hauptsaechlich um Fehlermeldungen oder Hilfetexte geht. Weiss aber nicht, wo es aufhoert:
- soll on/off uebersetzt werden?
- soll set/get uebersetzt werden?
- soll notify/at uebersetzt werden?
Beispiel:
definiere schalterDreher als Benachrichtigung wenn Schalter:an setze Lampe aus
mit
define -> definiere
notify -> [als] Benachrichtigung [wenn]
set -> setze
on/off -> an/aus
Um nicht alle zu verstoeren, die Programmstuecke kopieren wollen, wuerde ich bei den Argumenten bleiben wollen.
Diese tauchen leider an unterschiedlichen Stellen auf, deswegen bleibt einem das Uebersetzen nicht erspart.
Aber zurueck zum ersten Problem: gettext ja oder nein. Ich wuerde gerne den Italiener rechtzeitig bremsen :)
aua.
ich weiß nicht ob man sich mit einer solchen übersetzung der schlüsselworte wirlich einen gefallen tut oder nur potential für missverständnisse und schwer zu findender probleme schafft.
ob gettext oder nicht hängt genau davon ab was wirklich übersetzt werden soll.
Hallo,
würde höchstens statischen Text (Fehlermeldungen, Texte in Fhemweb, Rückmeldungen, Doku) übersetzen und keinesfalls Readings, Settings oder die FHEM-Sprache und auch nur, wenn es externe Maintainer gibt - ich habe schon jetzt keine Lust darauf, Doku in zwei Sprachen zu pflegen.
Performance muss auch stimmen, wäre aber wohl mit den o.g. Einschränkungen unproblematisch, da FHEM im laufenden Betrieb ja nicht mit dem Anwender kommuniziert und demzufolge auch nichts übersetzt.
Kenne gettext aus meinen anderen Projekten und finde es dort gut, zumal der Code lesbar bleibt. Habe aber keine Erfahrungen damit unter perl.
Grüße
Boris
Sehe ich auch so...