2009-10-05 18 views
10

Mam istniejącą aplikację WinForm opracowaną przy użyciu VS 2005 i .NET Framework 2.0.Globalizacja istniejącej aplikacji Windows Forms?

Teraz musimy globalizować tę aplikację. Te dwie lokalizacje są niemieckie i japońskie.

Wiem, że możemy użyć własności zlokalizować forma do tworzenia zlokalizowanych zasobów formularzy i mogą mieć inne pliki zasobów ciągów stosowanych w polach wiadomości, wyjątków itp ..

Chcę wiedzieć, najlepsze podejście do globalizacji istniejącej aplikacji , czy powinienem ustawić właściwość lokalizacyjną w każdym formularzu, czy jest jakieś narzędzie, które wyodrębni nazwy etykiet i nazwy kontrolne? Jakie rozważania należy podjąć dla formatów daty, waluty itp.

Również użyliśmy jakiegoś złożonego ciągi znaków w niektórych miejscach kodu, aby połączyć ciągi komunikatów, w jaki sposób można je zlokalizować?

Będziemy migrować aplikację do VS 2008 i .NET framework 3.5 przed rozpoczęciem działań związanych z globalizacją.

Odpowiedz

7

Pracowałem tylko z językami LTR i nie dotknąłem japońskiego. Mając to na uwadze, oto niektóre z moich najlepszych praktyk przy mojej głowie:

  • Umieść wszystkie specyficzne dla języka programowe struny i fragmenty strun w .resx pliku (Lubię używać jednego pliku .resx za okno dialogowe), a następnie wywołaj łańcuchy, korzystając z automatycznie generowanych klas i właściwości. W twoim kodzie nie powinno być żadnych napisów specyficznych dla języka (co oznacza prawie brak ciągów w kodzie, kropka). Dobrym wzorem jest także umieszczanie łańcuchów formatujących w .resx, ponieważ składnia języka jest różna.
  • Ustaw właściwość Localizable na wartość True we wszystkich formularzach i bezpośrednio na niej wprowadź zmiany dotyczące języka (użyj właściwości Language).
  • Zaprojektuj swoje formularze tak, aby wszystko, co wyświetla napisy specyficzne dla języka, będzie miało dodatkową przestrzeń tam, gdzie jest to konieczne (uwaga: język niemiecki jest dłuższy niż angielski). IMO, formularze nie muszą być całkowicie przegrupowywane w celu wprowadzenia podstawowych zmian w języku - może to jednak wymagać języka podobnego do japońskiego.
  • W przypadku elementów sterujących, takich jak etykiety wymagające dynamicznego ustawienia tekstu, należy ustawić tekst w formularzu, aby wiedzieć, że jest to tylko znacznik. Używam do tego "##", który naprawdę się wyróżnia. Unikaj ustawiania tekstu na "próbkę" tekstu dynamicznego, ponieważ nigdy nie będziesz pamiętał, które kontrolki ustawiają się dynamicznie, po prostu patrząc na formularz.
+0

Dzięki. Chciałbym poznać łatwość konserwacji i skalowalność z tym podejściem, jeśli coś jest zmienione lub tekst musi zostać zmieniony w pliku zasobów. Jeśli chcę rozszerzyć to na jeszcze jeden język, to jak to zostanie osiągnięte, jeśli aplikacja jest już w produkcja? Czy wymaga ponownej kompilacji i ponownego wdrożenia. – ksa

+0

Dzięki takiemu podejściu musiałbyś przekompilować i ponownie zainstalować główny plik wykonywalny zarówno dla dodania, jak i zmiany, tak. Ale musiałbyś przerobić _something_ na jakąkolwiek prostą wielojęzyczną implementację. Nie uważam tego za problem, ponieważ ciągi językowe powinny być sprawdzane przed sprawdzeniem poprawności pisowni/gramatyki, a dodanie nowego języka, którego chce klient, powinno być stosunkowo rzadkim zjawiskiem. –

+0

Dodanie nowego wsparcia językowego jest wymagane w naszej aplikacji. Jeśli nie ma zmian w aplikacji, z wyjątkiem języka, możemy utworzyć nowy plik .resx, wygenerować zestaw satelity i umieścić go w odpowiedniej strukturze katalogów. To nie będzie wymagało ponownego kompilowania, czy mam rację? Jeszcze jedno pytanie brzmi: tłumaczenie wprowadzonych danych użytkowników, gdzie i jak je zachować, jeśli mamy dane, które można udostępniać użytkownikom różnych lokalizacji? – ksa

1

Jeśli używasz Visual Source Safe jako kontrolki źródła (miejmy nadzieję, że nie jesteś), cokolwiek robisz, nie dodawaj tekstu japońskiego do kodu źródłowego. Chociaż Visual Studio obsługuje pliki źródłowe Unicode, VSS nie radzi sobie z nimi dobrze.

Pracowałem nad aplikacją, która przełożyła się na język japoński, a włączenie japońskiego do samego kodu źródłowego (dla wywołania funkcji podobnej do MessageBox) spowodowało uszkodzenie plików, a ponieważ VSS jest oparty na różnicach, pliki były uszkodzony z powrotem do oryginalnych wersji. To zepsucie przybrało formę większości plików kodu, które zostały przekształcone w bełkot japoński oparty na znakach, i pojawiły się, ponieważ VSS przesunął fragmenty plików CS opartych na Unicode (które używały dwóch bajtów na znak) wyłączonych o jeden bajt.

Naprawianie tych plików wymagało ogromnej pracy ręcznej, a mój szef zaglądał mi przez ramię i krzyczał, że jesteśmy zgubieni, więc nie rób tego.

A oto kilka innych pytań stackoverflow na ten temat:

Best way to implement multi-language/globalization in large .NET project

Best practice to make a multi language application in C#/WinForms?

Osobiście wolę prostsze metody. Stwórz listę w Excelu lub coś z każdego fragmentu tekstu angielskiego w aplikacji, którą musisz przetłumaczyć (kontroluj właściwości tekstu, łańcuchy znaków do użycia w funkcjach MessageBox itp.) I wyślij arkusze kalkulacyjne do tłumaczy. W swojej aplikacji wywołaj metodę w zdarzeniu Wczytaj każdego z formularzy, który jest iterowany za pomocą wszystkich formantów w formularzu i zmienia właściwości Tekst na przetłumaczone wartości. Zamień wszystkie połączenia na MessageBox, wywołując funkcję pośrednią, która tłumaczy tekst, który ma zostać wyświetlony, a następnie wywołuje MessageBox z przetłumaczonym tekstem.

Korzystanie z wbudowanych metod globalizacji wymaga wiele pracy, ponieważ trzeba ręcznie utworzyć każdą zglobalizowaną formę, a następnie ręcznie zastąpić cały tekst tłumaczeniami, a to zadanie wymaga od programisty płynności. Wspomniana przeze mnie metoda jest wykonywana programowo i nie wymaga od programisty płynnego posługiwania się przetłumaczonymi językami.

+1

powinieneś był krzyczeć na swojego szefa, że ​​nie ma kopii zapasowej w miejscu. krzycz na niego po francusku, z japońskimi napisami. – Timmerz

+0

My * zrobiliśmy * kopię zapasową w miejscu - nazywał się "Visual Source Safe". Nigdy bym się nie spodziewał, że coś takiego zdoła zepsuć repozytorium z powrotem do oryginalnego pliku. – MusiGenesis

+0

oczywiście nie rozumiesz pojęcia kopii zapasowej. – Timmerz

0

Jeśli chcesz, aby społeczność była zlokalizowana, użyj zewnętrznego pliku XML. Spójrz na http://www.codeplex.com/url2jpeg, ten projekt open source jest zlokalizowany w ten sposób i korzysta z funkcji Reflection do automatycznej lokalizacji formularzy.

Do napisu wystarczy użyć ukrytej etykiety.

2

Lepiej jest ustawić właściwość lokalizacji na każdym formularzu, który wyodrębni nie tylko łańcuchy, ale także geometrię różnych komponentów, do podstawowego pliku .resx. W przypadku nominowanych języków jest mało prawdopodobne, aby oryginalne rozmiary komponentów dobrze pasowały do ​​tłumaczenia.

Generalnie nie zaleca się komponowania ciągów z fragmentów, ponieważ generalnie nie mapują one na ten sam wzorzec fragmentów w innym języku. Używanie sformatowanych ciągów znaków (String.Format) do zmniejszania wartości, tak, ale wszystko, co zależy od gramatyki i kolejności zdań w oryginalnym języku, prawdopodobnie nie pasuje.

Powiązane problemy