Tento článek mám ve WordPressu rozepsaný snad už rok. Jeho původní název zněl „ResourceBundle – stačí Javě beze změny?“. Plno věcí, které jsme původně jako Java vývojáři dělali my, postupně uzpůsobujeme tak, aby je mohli dělat web designeři. Na prezentační vrstvu zcela jistě patří lokalizované texty a zprávy, pro které standardně používáme ResourceBundly Javy, které se načítají z property souborů. Ideální model pro web developery je iterace: navrhnu stránku, vložím text do property bundlu, uložím, reloadnu stránku a kouknu jak to vypadá. V tomhle jednoduchém scénáři jsme však narazili hned na několik problémů.
Standardní PropertyResourceBundle se obvykle získává takto (to je mmch. cesta zmíněná v dokumentaci ResourceBundle):
ResourceBundle myResources =
ResourceBundle.getBundle("MyResources", currentLocale);
Takto načítaný property soubor („MyResources.properties“) musíme mít na classpath (kde samozřejmě není editovatelný) a musíme jej mít ve Ascii formátu zkonvertovaný utilitou Native2Ascii. Dalším problémem je sekvence, ve které se hledají konkrétní lokalizované varianty bundlu. Díky tomu, že Java původně vznikla hlavně pro desktopové aplikace se do posloupnost hledání bundlů dostává i bundle pro systémové locale stroje, na kterém aplikaci spouštíme. V případě volání metody getBundle s Locale(„cs“,“CZ“) se na anglickém Ubuntu hledá property bundle v této posloupnosti:
- messages_cs_CZ.properties
- messages_cs.properties
- messages_en_US.properties
- messages_en.properties
- messages.properties
Tuto věc jsem ještě před rokem nevěděl, a to možná také proto, že není nijak zmíněná v dokumentaci Javy.
Tak se nám těch problémů nakonec sešlo docela dost – na to, že řešíme takovou hloupost jako je lokalizace – že?
)
