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
Markus Volz schrieb: > 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. Geht schon...war aber, so wie ich das verstanden habe, nicht gefragt http://msdn.microsoft.com/en-us/library/ms788718.aspx http://blogs.microsoft.co.il/blogs/tomershamam/archive/2007/10/30/wpf-localization-on-the-fly-language-selection.aspx > 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 :-}
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.