Hallo alle zusammen,
folgendes Problem ich habe eine C# Application (Visual 2008 Express)
geschrieben.
Nun soll diese App in den Sprachen Deutsch,Englisch zur Verfügung
stehen.
Soweit so gut. Das kann man alles mit .resx Dateien machen.
Sollte auch nicht das grosse Problem sein.
Jetzt will ich aber folgendes machen:
Angenommen es liegt eine Ressourcedatei mit allen deutschen Texten vor.
Diese Texte kann man bestimmt irgendwie auslesen und in eine .xml
schreibe.
Diese deutschen Texte gespeichert in .xml bekommt ein Kunde. Der kann
dann
mit einem anderen Tool die .xml öffnen. Und sieht dann die deutsche
Texte und kann in einer Spalte nebendran in z.B die englische Sprache
übersetzen.
Die englische Übersetzung soll dann ebenfalls in .xml gespeichert
werden.
Ich bekomme dann wieder die .xml mit den englischen Texten und will
diese
Texte wieder in ein Ressourcedatei speichern. Und zwar will ich die
nicht per Hand in die .resx eintragen sondern automatisch. Und ich glaub
genau
beim schreiben in die Ressourcedatei liegt das Problem.
Ich hoffe es ist verständlich worauf ich hinaus will
Ich schrieb:> Hallo alle zusammen,>> folgendes Problem ich habe eine C# Application (Visual 2008 Express)> geschrieben.> Nun soll diese App in den Sprachen Deutsch,Englisch zur Verfügung> stehen.>> Soweit so gut. Das kann man alles mit .resx Dateien machen.> Sollte auch nicht das grosse Problem sein.>> Jetzt will ich aber folgendes machen:>> Angenommen es liegt eine Ressourcedatei mit allen deutschen Texten vor.>> Diese Texte kann man bestimmt irgendwie auslesen und in eine .xml> schreibe.
Öffne doch mal die resx mit einem Texteditor...
Das ist XML und das Schema wird am Anfang erklärt
Arc Net schrieb:> Öffne doch mal die resx mit einem Texteditor...> Das ist XML und das Schema wird am Anfang erklärt
Euch ist aber hoffentlich klar, dass die Ressource-Datei auch compiliert
werden muss und dabei in die Assembly integriert wird? Kurz mal eine
Änderung am Ressourcefile beim Kunden und schon sieht man andere Texte
funktioniert leider nicht.
Gruß
Markus
Meinen die bei Microsoft den Eintrag in der MSDN dort ernst? Ich hab
immer gedacht, QT sei schon umständlich wg. Metaobjekten und qmake und
so weiter.
Genau so, wie der TO es beschreibt, funktioniert das mit QT: Mit
'lupdate' werden sämtliche Zeichenketten aus Programmtext und Formularen
in ein XML-Format überführt. Die können dann nach Belieben übersetzt
werden, etwa mit dem QT-Linguist. Mit 'lrelease' werden übersetzte
XML-Datensätze dann komprimiert und können einfach ins
Sprachressourcen-Verzeichnis auf dem Zielcomputer kopiert werden, ganz
ohne DLL oder Neucompilierung.
Sowas gibts doch mit absoluter Sicherheit auch für WPF/.NET -- das
Gefrickel in der MSDN mit dem CSV-Editor kann doch nicht ernst gemeint
sein, oder?
Hi
>> Sowas gibts doch mit absoluter Sicherheit auch für WPF/.NET -- das> Gefrickel in der MSDN mit dem CSV-Editor kann doch nicht ernst gemeint> sein, oder?
Doch leider meinen die das vollkommen ernst! WPF-Lokalisierung ist ein
schlechter Witz. Ohne Zusatztools (z.B. Sisulizer) für den
Produktiveinsatz nicht zu gebrauchen. Wir sind gerade dabei ein sehr
großes Projekt (> 120 komplexe Dialoge vom C++ Builder) nach .NET und
WPF zu konvertieren. In fünf Sprachen (darunter Japanisch und
Chinesisch). Da kann man schon mal verzweifeln. WPF kann alles und sieht
toll aus, ist aber auch heftigst komplex und immer noch in vielen Dingen
meilenweit von RAD entfernt. Es fehlen einfach viele Tools, die einem
die alltägliche Arbeit erleichtern. Naja, wir sagen immer: Wenn's
einfach wär', dann könnt's ja jeder ;-)
Gruß,
Oliver R. schrieb:> Hi>>>> Sowas gibts doch mit absoluter Sicherheit auch für WPF/.NET -- das>> Gefrickel in der MSDN mit dem CSV-Editor kann doch nicht ernst gemeint>> sein, oder?>> Doch leider meinen die das vollkommen ernst! WPF-Lokalisierung ist ein> schlechter Witz. Ohne Zusatztools (z.B. Sisulizer) für den> Produktiveinsatz nicht zu gebrauchen.
Kommt drauf an:
- LocBaml + x wenn sich die fertige Anwendungen nicht mehr ändert und
alles auf einmal übersetzt werden soll
- Resx was direkt im VS unterstützt wird
http://www.codeproject.com/KB/WPF/WPF_Resx_Localization.aspx
- Custom Markup http://www.wpftutorial.net/LocalizeMarkupExtension.html
- Third-Party ala Sisulizer
Der Weg ist nur nicht mehr so vorgegeben wie mit WinForms
Da muss man Oliver Recht geben.
Das ist für den produktiven Einsatz nahezu unbrauchbar. Auch die
Variante mit Ressourcen-Dateien ist wohl eher hinterher
hineingefrickelt, als von vornherein durchdacht :-/
Sven P. schrieb:> Da muss man Oliver Recht geben.> Das ist für den produktiven Einsatz nahezu unbrauchbar. Auch die> Variante mit Ressourcen-Dateien ist wohl eher hinterher> hineingefrickelt, als von vornherein durchdacht :-/
In VS: Neue Resource hinzufügen für die autom. eine Klasse erzeugt wird
mit der man auf die enthaltenen Texte, Icons, Dateien etc. zugreifen
kann (inkl. Codevervollständigung).
Für jede Sprache eine Kopie erzeugen (Icons und Dateien kann man
natürlich in eine separate Resource packen, falls diese nicht übersetzt
werden sollen, fertig.
Qt:
im Quelltext tr("translate me")
d.h. keine Codevervollständigung und man muss bei jeder Verwendung auf
die Schreibweise achten
QML: Text { text: qsTr("translate me") }
.NET:
Resource (angenommen TR):
im Quelltext TR.Translate_Me
XAML z.B. Text="{TR Translate_Me}" (falls man eine Mischung aus Resx und
XAML-Erweiterung nimmt oder man nutzt die Resource direkt (mehr
Schreibarbeit, dafür Codevervollständigung))
Die Qt-Variante mit Strings kann man, wenn man will, auch umsetzen...
Sicher funktioniert die WPF-Lokalisierung vom Prinzip her. Aber man muss
auch bedenken, dass die Leute, die die SW dann übersetzen sollen
meistens keine SW-Entwickler sind und mit der Installation vom VS,
geschweige denn dessen Benutzung, völlig überfordert sind.
Auch kommt es oft vor, dass wir an Dialogen weiterarbeiten, dessen
Übersetzung aber noch andauert und dann nachträglich eingepflegt werden
muss. Für all dies wünsche ich mir Tools, die die alltägliche Arbeit
erleichtern. WinForms war da z.B. schon viel weiter. Für den geneigten
SW-Entwickler gibt es meiner Meinung nach nichts langweiligeres, als
sich mit der Lokalisierung der eigenen Software herumzuplagen. Bei uns
sind es halt so viele Texte (mehrere zehntausend Wörter...), dass
jegliche Behinderungen des Workflows einen in die Tastatur beißen
lassen...
Bei MS scheint WPF-Lokalisierung leider kein großes Thema zu sein, ich
hatte schon mal im MS Connect für eine Verbesserung plädiert, bisher
ohne Erfolg und ohne viele Votes. Wer mag, der votet mit:
https://connect.microsoft.com/VisualStudio/feedback/details/540019/wpf-localization-needs-enhancement
Gruß,
Oliver
Hallo,
> Für all dies wünsche ich mir Tools, die die alltägliche Arbeit erleichtern
Wir (Neovelop) arbeiten gerade daran, diesen Wunsch zu erfüllen ;-).
NLocalize ist ein Lokalisierungstool speziell für WPF (und bald auch
Silverlight + WP7). NLocalize ist direkt in Visual Studio 2010
integriert. Über einen Assistenten wird NLocalize konfiguriert und
danach automatisch beim Build ausgeführt. Bei jedem Build werden so
Ressourcendateien zu den WPF Dialogen erstellt bzw. schon vorhandene mit
den XAML-Dateien abgeglichen. Die Ressourcendateien die dabei entstehen
kann man entweder direkt in Visual Studio bearbeiten (NLocalize bietet
dafür einen eigenen Editor), oder über eine eigene Anwendung für
Übersetzer.
Auf unserer Webseite (http://www.neovelop.de/nlocalize) gibt's ein
Video, da könnt ihr euch anschauen, wie das ganze funktioniert.
Von anderen Anbietern gibt's da z.B. Sisulizer, Alchemy Catalyst, Visual
Localize, Lingobit Localizer und noch einige andere. Das sind allerdings
"ganz allgemeine" Tools, die sich nicht auf WPF/XAML-Lokalisierung
spezialisiert haben und sich auch nicht direkt in Visual Studio
integrieren.
Falls kein Budget für irgendwelche Tools vorhanden ist gibt's auf
http://wpflocalization.codeplex.com/ einen Vergleich verschiedener
Lokalisierungsansätze. Die sind allerdings alle mit viel zusätzlicher
Arbeit verbunden, da bezahlt man dann mit höherem Entwicklungsaufwand
statt mit Lizenzgebühren.
Von NLocalize gibt's bald eine erste Beta. Wenn ihr möchtet meldet euch
auf nlocalize.de für das Early Access Program an, dann könnt ihr die
Beta ganz unverbindlich ausprobieren. Ihr könnt es euch auch auf einer
der nächsten Community Konferenzen anschauen (dotnet Cologne, .NET Day
Franken, See# Party, NRWConf), wir sind da jeweils als Sponsor vor Ort.
Grüße,
Mathias
Twitter: @nlocalize
http://www.neovelop.de
Arc Net schrieb:> Sven P. schrieb:>> Da muss man Oliver Recht geben.>> Das ist für den produktiven Einsatz nahezu unbrauchbar. Auch die>> Variante mit Ressourcen-Dateien ist wohl eher hinterher>> hineingefrickelt, als von vornherein durchdacht :-/>> In VS: Neue Resource hinzufügen für die autom. eine Klasse erzeugt wird> [...]
Njoa, diese Verfahren kenne ich ja, ich dachte nur, es gäbe da noch
etwas 'oben drauf'.
So ist es, wie ich bereits sagte, einfach unbrauchbar. Die Übersetzer
hier sind keine Programmierer :-}
