Lista Stron

Streszczenie


Pattern A Sprawa Polska

Czyli jak zmusić patterny żeby 'łapały' polskie znaki

Szybka notka:

Wzorzec zdefiniowany przez java.util.Pattern jest gotowy na przyjęcie Polskich znaków, natomiast nie wszystkie predefiniowane klasy akceptują je.

W szczególności \w, określana jako word character nie machuje polskich znaków.

czyli:

    "ą".matches("\\w") == false

Klasą przyjmującą znaki słów spoza bloku ASCII jest \p{L}.

Jakby ktoś chciał poczytać dokładniej to niech poczyta:

data: 13 Dec 2009 22:56 tagi: internacjonalizacja regexp


Swing Internatonalize

Internalizacja komponentów swinga

Notka dotyczy internacjonalizacji komponentów swinga, takich jak JFileChooser, JOptionPane i tak dalej, a nie całej aplikacji swingowej.

Nie ma dobrej metody na internacjonalizacje komponentów swinga, większość jest w jakiś sposób zła, niektóre są jednak mniej złe od innych.

Natywne Look and Feele które powinny wyświelać natwne komponenty prawodopodobnie używają locale systemowego i będą działać same. Natomiast Look and Feele Javy (metal, nimbus) pobierają napisy z UIDefaults. Rzeczywiście w UIDefaults są klucze takie jak FileChooser.cancelButtonText=Cancel.

Rozwiązanie złe

Pierwszym rozwiązaniem jest więc po prostu zrobienie czegoś takiego:

    UIManager.put("FileChooser.cancelButtonText", "Anuluj");

jednak dla mnie jest to rozwiązanie złe z kilku powodów głównie z tego powodu że gdzieś w inicjalizacji programu muszę pamiętać zeby te klucze ustawić i muszę je ustawiać zawsze po zmianie Look and Feela. Co więcej po czymś takim program będzie miał na sztywno ustawione jedno locale, to znaczy bez względu na locale systemowe standardowe komponenty swinga są po polsku. Oczywiście można by to costumizować żeby jeśli locale to pl_PL ustawiać te klucze w UIManagerze, a jeśli fr_FR to nie. Ale to już jest komplikowanie sobie życia…

Rozwiązanie w złe, ale lepsze niż poprzednie

Trzeba więc poszperać dalej. Poszperałem dalej na własną rękę i znalazłem w standardowej dystrybucji javy następujące paczki:

paczki-lokalizacja.png

Wyglądają one łudząco podobnie do normalnego ResourceBoundla który służy do internacjonalizacji. Starczy do tej paczki dodać ResourceBoundla z polskimi napisami i nasz progam automagicznie będzie miał dobre Locale :).

Dodam że starczy w tej paczce umieścić plik metal_pl.properties1, a automagicznei powstanie z niego resource bundle.

Wszystkie klucze z lokalizacją są w (nieprzetłumaczonym jeszcze) pliku metal_pl.properties.

No i wreszcie — jak umieścić ten plik w paczce (bądź co bądź) com.sun.*, czy trzeba rozpakowywać jary JRE. Otóż wcale niekoniecznie, starczy stworzyć taką paczkę w twoim jarze, w którym jest Twój program a JRE już sobie odpowiednie pliki znajdzie :).]

PS. A dlaczego jest to rozwiązanie złe? Głownie dlatego że jednak grzebie się w klasach com.sun.*, które moga się zmieniać nie tylko z wersji na wersje Javy, ale wręcz mogą zmieniać wraz z updejtami, updejtami bezpieczestwa i tak dalej.

A co z nimbusem

Wydaje mi się że Nimbus jest automagicznie naprawiony kiedy naprawimy Metala. Rzut oka na klasy z JRE i widzimy że Nimbus dziedziczy po Metalu.

data: 13 Dec 2009 22:41 tagi: internacjonalizacja swing


O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License