C# - globalizacja aplikacji

Chciałbym żeby moja aplikacja obsługiwała 2 języki (angielski, polski). Odblokowałem na oknie opcje Localizable następnie ustawiłem wszystkie paremetry językowe pod English (Polski jest jako default) i nie wiem jak zmienic język spod aplikacji tzn. żeby klikając na przycisk zmienic jezyk na angielski. Używam VS2008EE

Musisz to “ręcznie” zaprogramować. Po naciśnięciu przycisku, musisz zmienić wszystkie teksty na dany język, nic się samo nie zrobi.

Wiem, ale jak zaprogramowac ze jak klikne przycisk to sie zmieni jezyk - chodzi mi o kod takiej funkcji.

To zależy od aplikacji. Ja bym to zrobił tak:

  • Robimy tablice tekstów w programie.

  • Wypełniamy ją domyślnym językiem.

  • Wszystko wyświetlamy używając tekstów z tej tablicy.

  • Gdy użytkownik kliknie na “zmień język”, podmieniamy tablice na tą z wybranym językiem.

  • Odświeżamy kontrolki.

Najlepiej skorzystać z istniejących rozwiązań:

String Resource Files (SR.strings)

http://www.mono-project.com/Internationalization

Na jedno wychodzi. Tylko tu potrzeba Mono, a moje rozwiązanie tego nie potrzebuje. I nie zawaham się powiedzieć, że jest szybsze, bo nie potrzeba rekompilacji.

Rozwiązanie z Mono nie wymaga rekompilacji.

I działa tylko z Mono, plik jest większy(niepotrzebne IMHO dane z Glade).

Glade nie jest potrzebny. Jak sam sobie napiszesz taki mechanizm to plik wynikowy też będzie większy, a jest duża szansa, że będzie gorzej napisany niż istniejące obecnie.

Dołączać plik do zasobów IMHO jest gorszym rozwiązaniem niż wpisać go na sztywno do kodu. Jeśli chcemy wymagać wielu języków, to najlepiej trzymać je w osobnych plikach.

Ja robie to przez dll wszystkie napisy wpakowane w dll, podmieniasz dll to sie zamienia jezyk. można to tez używać w runtime.

Kolejny pomysł IMHO nie warty świeczki w małych aplikacjach. Jeśli nie ma zamiaru udostępniać tłumaczeń aplikacji, to nie potrzeba mu nic innego, jak tylko tablica.

DLL też jest złym rozwiązanie, zmiana czegoś równa się ponownej kompilacji tej DLL-ki. Lepiej użyć pliku tekstowego(własny format, XML, etc.).

Owszem zmiana czegoś równa się ponownej kompilacji tej DLL-ki, lecz środowisko robi to automagicznie , wiec niema się czym przyjmować. Zastosowałem takie rozwiązanie w 5-ci średnich i dużych projektach, bez żadnych kłopotów. Przed tym raz stosowałem plik tekstowy, w wyniku czego cztery razy jeździłem do klienta, program zaczynał złe działać po grzebaniu klienta w pliku. Jeden raz powywalał ampersandy w kilku formatkach, drugi raz zmienił hint’a z “naciśnij F5” na “naciśnij F6” i dziwił się czemu F6 nie działa, trzeci raz zachował w formacie *.doc i zmienił rozszerzenie na poprzednie, czwarty raz usunął z wiersza wszystkie \n w związku z czym na ekranie widział tylko część tekstu. Po czwartej wizycie ustawiłem dla pliku atrybut ReadOnly i przyrzekłem już nigdy nie używać tego rozwiązania.