i18n met resource bundles worden een zooitje.

[Standeman]

We zijn hier hard bezig een JSF applicatie te bouwen welke meerdere talen kan ondersteunen. Op zich niet moeilijk, we proppen gewoon alles in resourcebundle welke we laten vertalen.

Echter, beginnen de resourcebundles een beetje een zooitje te worden. Als je in de resource bundles kijkt is het lang niet altijd duidelijk waar de key voor staat. Er zit geen consistentie in en zo zijn er nog wel wat problemen en onduidelijkheden.

Aangezien ik dit netjes wil gaan oplossen zodat alles eenduidig is, ben ik op zoek naar een structuur / best practice dat een duidelijke mapping geeft tussen property en label.

Op het moment ziet het ongeveer zo uit:

code:

product_tooltip_application=tooltip
product_click_to_edit=Click to edit
OutputLabel=Output
EncryptLabel=Encrypt
application_label_name=Name
DecryptLabel = Decrypt

Zelf had ik het volgende bedacht voor onderdelen die met het object-model te maken hebben:

code:

# Volledige naam voor bijv. formulier labels
<object>_<attribute> =<value>

# Afgekorte naam voor bijv. column headers
<object>_<attribute>_abbr=<value>

# Omschrijving voor bijv. tooltips
<object>_<attribute>_descr=<value>

Voorbeeld:
employee_phone=Telefoonnummer
employee_phone_abbr=Tel.nr.
employee_phone_descr=Het prive / mobiele nummer waar de werknemen op bereikbaar is.

Specifieke controls, bijv. "Add Employee" button.

code:

<object>_<control>_<action>=<value>
<object>_<control>_<action>_descr=<value>

Voorbeeld:
employee_button_add=Toevoegen
employee_button_add_descr=Voegt een nieuwe werknemer toe.

Generieke controls, bijv "Back" button:

code:

<control>_<action>=<value>
<control>_<action>_descr=<value>

Voorbeeld:
button_back=Terug
button_back_descr=Navigeer naar de vorige pagina

Ik vraag me af of dit zo'n beetje alles dekt wat je in een webapplicatie tegen kan komen qua tekst en of ik op de goede weg zit. Heeft er iemand nog iedeeen? Ik wil uiteraard voorkomen dat ik voor verassingen kom te staan of over een paar weken toch weer de heleboel moet omgooien.

[NetForce1]

Volgens mij kun je beter keys groeperen dmv punten. Dit wordt vaak ook ondersteund door resource bundle editors waarin je dan een tree structuur krijgt. Verder kun je makkelijk je keys prefixen voor een bepaalde context waarbij je dan in je code niet de hele key hoeft op te geven iedere keer, alleen het gedeelte wat achter de prefix geplakt moet worden.

[ Voor 40% gewijzigd door NetForce1 op 06-06-2008 10:58 ]

[Standeman]

Om de een of andere reden wil JSF niet werken met punten. De foutmelding die ik dan krijg:

code:

javax.faces.el.PropertyNotFoundException:
value="#{bundle.test.mypoint.menu}" 
Error getting property 'mypoint' from bean of type java.lang.String

En hoe bedoel je het prefixen voor een bepaalde context. Zou je daar een klein voorbeeldje van kunnen geven?

[Janoz]

Dat was inderdaad ook een van mijn grootste ergenissen met JSF. De punten worden geinterpreteerd als 'getters'. Ik heb ergens wel eens een oplossing gezien, maar die kan ik nu zo snel even niet terug vinden. Het zal waarschijnlijk iets zijn geweest waarbij een eigen implementatie van de property resolver werd gebruikt.

[NetForce1]

Standeman schreef op vrijdag 06 juni 2008 @ 11:18:
En hoe bedoel je het prefixen voor een bepaalde context. Zou je daar een klein voorbeeldje van kunnen geven?

Je hebt bijv. de keys 'dialog.dlgname.action.discardChanges.mnemonic', 'dialog.dlgname.action.discardChanges.caption', 'dialog.dlgname.action.discardChanges.description'. Dit is niet zo fijn om in je code te hebben (net als dat je niet overal fully qualified class names gaat gebruiken). Wat wij nu hebben is een Messages class waaraan je een prefix mee kunt geven, bijv:

Java:

messages = new Messages("dialog.dlgname.action.discardChanges")

nu kun je de andere keys simpel benaderen door

Java:

messages.getString("caption");
messages.getString("mnemonic");
messages.getString("description");

Maar wij werken niet met jsf, dus of een soortgelijke aanpak daar ook gaat werken zou ik niet durven zeggen.

[Kettrick]

Standeman schreef op vrijdag 06 juni 2008 @ 11:18:
Om de een of andere reden wil JSF niet werken met punten. De foutmelding die ik dan krijg:

code:

javax.faces.el.PropertyNotFoundException:
value="#{bundle.test.mypoint.menu}" 
Error getting property 'mypoint' from bean of type java.lang.String

En hoe bedoel je het prefixen voor een bepaalde context. Zou je daar een klein voorbeeldje van kunnen geven?

Je kan het ook op deze manier aanroepen :

code:

#{bundle['test.mypoint.menu']}

dat zou gewoon moeten werken.

[Standeman]

RoeLz schreef op vrijdag 06 juni 2008 @ 11:46:
[...]


Je kan het ook op deze manier aanroepen :

code:

#{bundle['test.mypoint.menu']}

dat zou gewoon moeten werken.

Hey, die kende ik nog niet. Ik ga het gelijk even proberen.

En het werkt \o/ Dat is al een redelijke vooruitgang!

[ Voor 8% gewijzigd door Standeman op 06-06-2008 12:28 ]

[Standeman]

even een schopje.

Ik kom een andere uitdaging tegen. Ik wil de resource key variabel opbouwen in mijn JSF pagina. Om een even te illustreren:

code:

tag.9F07=AUC
tag.9F07.descr=Application Usage Control

In mijn object kan ik de tag ophalen door bijv foo.getTag();

Nu wil ik eigenlijk dynamisch de key opbouwen

code:

String key = "tag." + foo.getTag() = ".descr".

Ik zit me nu alleen even af te vragen hoe ik dat in mijn bundle['xxx'] ga krijgen

[ Voor 3% gewijzigd door Standeman op 25-06-2008 08:58 ]

[Confusion]

bundle[key] zou volgens mij gewoon moeten werken, als de JSP 2.0/2.1 EL regels gelden. Ik weet alleen niet zeker of dat ook voor deferred evaluation geldt.

[ Voor 68% gewijzigd door Confusion op 25-06-2008 09:04 ]

[Standeman]

Dat werkt inderdaad prima. Nu nog een manier vinden om de geconcateneerde string er in te prutsen.

hmmm het volgende lijkt niet te werken:

code:

<c:set var="tag" value="#{foo.tag}.descr" />
<outputText value="bundle[tag]"/>

Ook vind ik het eigenlijk niet zo relaxed om JSTL en JSF te mixen..

[ Voor 55% gewijzigd door Standeman op 25-06-2008 10:26 ]

[Standeman]

Iemand een idee?

[Confusion]

Standeman schreef op woensdag 25 juni 2008 @ 09:51:
hmmm het volgende lijkt niet te werken:

code:

<c:set var="tag" value="#{foo.tag}.descr" />
<outputText value="bundle[tag]"/>

edit:
Wat hier stond is iets anders dan wat je vraagt.

Wat is de waarde van tag dan nadat die gezet is?

Ah, wacht eens, dat moet iets van

code:

<outputText value="#{bundle[tag]}"/>

zijn. Anders wordt 'tag' helemaal niet als variabele geinterpreteerd, maar heeft gewoon de letterlijke stringwaarde 'bundle[tag]'

Ook vind ik het eigenlijk niet zo relaxed om JSTL en JSF te mixen..

Met alleen JSF kom je niet zo ver; JSF is in feite een uitbreiding van het JSP/EL/JSTL met een lifecycle (en deferred evaluation en de mogelijkheid om een EL expressie als setter te laten fungeren). Voldoende situaties waarin EL/JSTL nuttig waren worden niet door JSF opgelost.

[ Voor 30% gewijzigd door Confusion op 25-06-2008 22:49 ]

[JKVA]

Over die outputText, je kunt altijd naar Facelets kijken. Dat is een veel krachtigere view definition taal dan JSP. In Facelets kun je bijvoorbeeld gewoon dit doen:

XML:

<html>
<body>
<h1>#{bundle[tag]}</h1>
</body>
</html>

Geen outputTexts meer nodig. Krijg je veel schonere pagina's van. Ook qua EL heb je voordelen, want met Facelets kun je EL 2.1 (de EL uit JSF 1.2) gebruiken in een JSF 1.1 omgeving.

[Standeman]

Ah.. ik zie dat ik een foutje heb gemaakt. Ik was de #{} vergeten op te nemen in mijn post.

Er staat wel degelijk

code:

<c:set var="tag" value="#{foo.tag}.descr" />
<outputText value="#{bundle[tag]}"/>

Het lijkt er alleen op dat de c:set niet werkt.

[Confusion]

Want wat is de waarde van #{tag} na de set?

[Standeman]

Helemaal niets

[JKVA]

Het is lang geleden dat ik JSF met JSP gebruikt heb, maar probeer eens ${tag}. Wat komt daar uit?

c:set is namelijk geen JSF tag library, maar JSTL. En de lifecycles van die twee matchen niet lekker.

[Standeman]

Ik heb eindelijk het probleem gevonden

Ik had xmlns:c="http://java.sun.com/jsp/jstl/core" i.p.v. xmlns:c="http://java.sun.com/jstl/core"

Dan wordt blijkbaar de JSTL gewoon overgeslagen zonder dat je een foutmelding krijgt. c:set werkt nu eindelijk!

[Confusion]

JKVA schreef op vrijdag 27 juni 2008 @ 11:25:
c:set is namelijk geen JSF tag library, maar JSTL. En de lifecycles van die twee matchen niet lekker.

De JSTL is aangepast zodat deferred evaluation er ook mee werkt; in principe zou het dus geen problemen op moeten leveren.

[JKVA]

Confusion schreef op vrijdag 27 juni 2008 @ 13:52:
[...]

De JSTL is aangepast zodat deferred evaluation er ook mee werkt; in principe zou het dus geen problemen op moeten leveren.

Klopt, als je de goeie taglib gebruikt. Standeman is niet de eerste die dit overkomt. Voor Facelets is de hele toko herschreven om het te integreren, anders werkte het niet. Het is ook afhankelijk van de JSP/JSF versie die je gebruikt.

[Verwijderd]

JKVA schreef op donderdag 26 juni 2008 @ 08:23:
[...]
Geen outputTexts meer nodig. Krijg je veel schonere pagina's van.

Alleen gooi je dan de mogelijkheid weg om je output te escapen, zoals bijvoorbeeld ampersands. Het outputText element kent immers het 'escape' attribuut. Ik vind het om die reden dus altijd zeer wenselijk om tags te gebruiken om text te printen. Je kunt dan immers de intentie van wel of niet escapen kenbaar maken.

[JKVA]

Verwijderd schreef op zondag 06 juli 2008 @ 10:20:
[...]
Alleen gooi je dan de mogelijkheid weg om je output te escapen, zoals bijvoorbeeld ampersands. Het outputText element kent immers het 'escape' attribuut. Ik vind het om die reden dus altijd zeer wenselijk om tags te gebruiken om text te printen. Je kunt dan immers de intentie van wel of niet escapen kenbaar maken.

Klopt, maar dat heb je niet altijd nodig. En dan is een extra tag alleen maar extra verbose.