Aplikacja wielojęzykowa - język zmieniany bez restartu

0

Cześć, temat był wałkowany, ale ja chcę spojrzeć na niego trochę inaczej. Stworzyłem sobie mechanizm do obsługi językowej aplikacji. Wszystko opiera się o plikach INI. No i ładnie działa. Jednak, jeśli podczas działania aplikacji, zmienimy język, to gdy inne formy będą otwarte (chociażby główna), język nie ulegnie na nich zmianie. Wymaga to restartu aplikacji. Ale ja chcę sobie trochę utrudnić życie. Tylko zastanawiam się, w którą stronę. Chcę uzyskać to, że po zmianie języka w ustawieniach, wszystkie otwarte formy zaczytają sobie nowe stringi bez konieczności restartu aplikacji. Problem niby nie jest ciężki, można by zastosować chociażby komunikaty Windows. Ale ja się zastanawiam, jak jeszcze to można zrobić. Moje pomysły:

  1. Jedna forma bazowa z abstrakcyjną metodą "Localize". Po tej formie dziedziczą wszystkie formy w aplikacji (łącznie z MainForm!). Po zmianie języka, forma bazowa przechwytuje komunikat i wywołuje metodę Localize.
  2. Podobnie do punktu 1, ale każda forma przechwytuje sobie ten komunikat. Nie ma jednej, głównej formy bazowej.
  3. Zastosowanie interfejsów. Mam interfejs z metodą "Localize", którą muszą przesłonić wszystkie klasy po nim dziedziczące. Obiekty "rejestrują" się w jakimś singletonie, np:
 
LanguageHelper.RegisterLangObject(self);

powoduje to dodanie obiektu do jakiejś listy w singletonie LanguageHelper. W momencie zmiany języka, language helper wywołuje metodę Localize w każdym obiekcie z tej listy.
4. Metoda podobna jak w punkcie 3, tyle że zamiast wywoływania RegisterLangObject, chcę się posłużyć atrybutami. Ale tutaj nie mam zielonego pojęcia jak to ugryźć. Dodatkowo może nie potrzebowałbym interfejsu, tylko mógłbym dodawać same metody?

Jak sądzicie, który sposób będzie najlepszy? Tzn. który sami byście wybrali? A może jeszcze coś innego? Chyba skłaniam się do ostatniego sposobu (jeśli się w ogóle da), który wydaje się sprawiać najmniej kłopotu i roboty podczas rozwoju aplikacji.

Sposób pierwszy ma co najmniej 2 minusy

  • MainForm, który dziedziczy po formie bazowej
  • Podczas dodawania nowych form powinienem pamiętać o formie bazowej.

Punkt drugi ma za dużo roboty (w każdej formie muszę robić to samo)

Punkt trzeci wymaga użycia dodatkowej metody.
Punkt czwarty w sumie chyba najlepszy (jeśli w ogóle się da), bo wydaje się sprawiać najmniej kłopotu i roboty podczas rozwijania aplikacji.

0

Zastanów się czemu wszystkie okna czekają na komunikat KeyPressed zamiast w pętli sprawdzać czy klawisz naciśnięto.

0

Osobiście mi najbardziej podoba się metoda 3. Tj rejestrująca interfejs do tłumaczenia w konstruktorze formy. Moim zdaniem możesz użyć jeszcze conajmniej jednego sposobu, tj. jeżeli tworzysz formy poprzez Application.CreateForm, to możesz iterować po wszystkich istniejących formach (po zmianie języka). Czyli możesz sprawdzić, czy dana forma implementuje Twój interfejs i ewentualnie wywołać metodę tłumaczącą. Ta propozycja zwalnia Cię z konieczności rejestrowania każdej tłumaczalnej formy w jej konstruktorze.

3

powiedz mi po co wymyślać koło od nowa kiedy są świetne narzędzia do tego, np. dxgettext . Ja wiem, że ty jesteś najlepszy i nikt nie napisze tak doskonałego rozwiązania ale może czasem warto spróbować wziąć gotowca, szczególnie jeśli jest przetestowany przez

0

Chcę to zrobić sam w ramach rozwoju :)

0

W ramach rozwoju powinieneś zrobić wszystkie te wersje a wtedy zobaczysz na własnej skórze co jest dobre a co złe.
Wszak większość i tak uczy się na własnych błędach.

1 użytkowników online, w tym zalogowanych: 0, gości: 1