[java] Eigen i18n systeem maken

[Verwijderd]

Wij zijn van plan om een redelijk grote java web applicatie te bouwen waarbij internationalisatie belangrijk zal zijn. Nu heb je in Java al langere tijd support voor i18n, en bieden frameworks als JSF ook direct support hiervoor.

Aangezien ik weinig ervaring met i18n heb, vroeg ik me af op je dit gewoon kunt gebruiken, of dat het beter is om zelf een systeem hiervoor te ontwikkelen.

Je zou de volgende punten van kritiek kunnen hebben op het standaard systeem:

-Standaard resource bundles zijn niet 'mooi'. Vooral de placeholders als {1} enzo kunnen als lelijk worden gezien.
-Voor elke taal heb je een aparte bundle. Je zou mischien liever per key alle talen bij elkaar hebben.
-Geen support voor 'lange' en 'korte' teksten.

Wat er voorgesteld werd is 1 grote resource bundle in XML formaat, die ongeveer de volgende structuur heeft:

XML:

<text key = "een_key">
   <locale type="een_locale">
        <short>text</short>
       <long> lange text </long>
  </locale>
</text>

Hierbij mag de text dan ook taglib tags en EL bevatten. Bijvoorbeeld:
<short> Hallo <outputText value="#{MyBean.name}" /> </short>

Wat denken jullie van dit systeem? Is het verstandig om dit te gebruiken ipv het standaard i18n systeem? Het voordeel van de standaard is natuurlijk ten eerste dat het de standaard is (en je hoeft geen eigen code te onderhouden). Daarnaast heb je veel tools die met de standaard resource bundles werken. Tevens heb je nog het voordeel dat vertaalbureau's opdrachten accepteren in het standaard resource bundle formaat. Dwz, je leverd een engelstalige bundle in, en krijgt een griekse terug.

Ik twijfel dus of ik voor het eigen systeem moet gaan omdat het mooier en beter is, of voor het standaard systeem omdat het standaard is (en mischien ook nog wel voordelen heeft die ik nu over het hoofd zie).

[ Voor 6% gewijzigd door Verwijderd op 20-05-2005 14:05 ]

[JaWi]

IMHO zijn je punten van kritiek op de huidige aanpak (dus individuele bundles per taal) niet echt steekhoudend:

- ``Ze zijn niet mooi (eventueel rekening houdend met placeholders)''; strikt genomen is geen enkele resource bundle bestand mooi, het is en blijft een zooi key-value pairen, of je het nu op de standaard Java-manier doet, of in XML verpakt;
- ``Aparte bundles per taal''; da's toch juist handig? Als je een nieuwe taal wilt ondersteunen hoef je maar een bestand aan te maken en uit te leveren;
- ``Geen support voor lange en korte teksten''; wat bedoel je hiermee? Dat je alles op een regel moet
plaatsen of zo? Want in resource-bundles je kunt values over meerdere regels verdelen door een '\' aan het einde van een regel te plaatsen?!

Verder als je kijkt naar de onderhoudbaarheid van je XML-formaat, dan lijkt mij dat nogal error-prone; een type-fout en je hele XML-bestand wordt niet meer correct ingelezen. Bij de standaard Java-resource bundles is dit een stuk minder.

edit:
Daarnaast: met een losse bundle voor elke taal is het inlezen theoretisch gezien sneller en minder "kostbaar" (qua geheugen, I/O, etc) dan het inlezen van een enkele bundle waarvan je 80 of 90% weggooit.

Daarnaast, je gaf het zelf al aan, zijn er genoeg tools op de markt die resource bundles kunnen onderhouden, zelfs voor meerdere talen tegelijkertijd (bijv. de ResourceBundle plugin voor Eclipse).

[ Voor 11% gewijzigd door JaWi op 20-05-2005 14:40 . Reden: extra hint ]

[FendtVario]

JaWi schreef op vrijdag 20 mei 2005 @ 14:34:

- ``Geen support voor lange en korte teksten''; wat bedoel je hiermee? Dat je alles op een regel moet
plaatsen of zo? Want in resource-bundles je kunt values over meerdere regels verdelen door een '\' aan het einde van een regel te plaatsen?!

De TS heeft hier zeker een punt. Het probleem bij vertalen is vaak dat teksten in sommige talen langer worden dan de 'originele applicatie taal'. Hierdoor moet je soms gaan schuiven met componeten omdat tekst achter bijv. een invoerveld verdwijnt. Ik heb hier met Java geen ervaring mee, maar ik heb het idee dat je dit al redelijk goed kan oplossen door de juiste LayoutManager in Swing te gebruiken. Met webapplicaties kan dit icm css misschien ook een probleem geven.

[Verwijderd]

JaWi schreef op vrijdag 20 mei 2005 @ 14:34:
- ``Geen support voor lange en korte teksten''; wat bedoel je hiermee? Dat je alles op een regel moet
plaatsen of zo? Want in resource-bundles je kunt values over meerdere regels verdelen door een '\' aan het einde van een regel te plaatsen?!

Sorry ja, dat was iets te onduidelijk geformuleerd. Het idee is dat je voor elke tekst een lange (uitgebreide) tekst hebt en een kortere. Op de manier kan je je interface schakelen tussen eentje met veel tekst en eentje met weinig, die echter wel het zelfde betekenen.

Iets in de trend van:

Long: "Hallo meneer Bla u bevindt zich nu in het hoofscherm van onze mooie applicatie"
short: "U bent in het hoofdscherm"

Etc

Verder als je kijkt naar de onderhoudbaarheid van je XML-formaat, dan lijkt mij dat nogal error-prone; een type-fout en je hele XML-bestand wordt niet meer correct ingelezen. Bij de standaard Java-resource bundles is dit een stuk minder.

Als je XML bestand niet meer correct gelezen wordt krijg je natuurlijk meteen een parse error bij het opstarten van de web applicatie.

De TS heeft hier zeker een punt. Het probleem bij vertalen is vaak dat teksten in sommige talen langer worden dan de 'originele applicatie taal'.

Ik zou graag een punt willen hebben maar dat is helaas niet van toepassing. Het is eigenlijk alsof je een extra 'sub-taal' hebt, dus Duits-lang en Duits-kort bijvoorbeeld. Zodat je je hele interface naar een beknoptere tekst versie kan omschakelen.
Met standaard resourcer bundles zou je dit waarschijnlijk doen door programatisch een andere bundle te laden.

[ Voor 21% gewijzigd door Verwijderd op 20-05-2005 15:08 ]

[JaWi]

FendtVario schreef op vrijdag 20 mei 2005 @ 15:01:
[...]
De TS heeft hier zeker een punt. Het probleem bij vertalen is vaak dat teksten in sommige talen langer worden dan de 'originele applicatie taal'. Hierdoor moet je soms gaan schuiven met componeten omdat tekst achter bijv. een invoerveld verdwijnt. Ik heb hier met Java geen ervaring mee, maar ik heb het idee dat je dit al redelijk goed kan oplossen door de juiste LayoutManager in Swing te gebruiken. Met webapplicaties kan dit icm css misschien ook een probleem geven.

Hmm, als je het over die boeg wilt gooien, dan heb ik er ook nog een: in sommige talen worden teksten van boven naar onder geschreven, of van rechts naar links. Hoe pak je dat aan?
Met andere woorden: je kunt geen enkele UI zo generiek maken dat het voor elke taal toepasbaar is. Je zult keuzes moeten maken, ook met de vertalingen (daarnaast moet je er sowieso nooit van uitgaan dat een component een fixed hoogte en breedte heeft!)

[ronaldmathies]

Jou oplossing heeft wel tot gevolg dat dit bijvoorbeeld niet meer gaat werken:

<f:loadBundle basename="mypackage.Messages" var="messages"/>

<h:outputLabel value="#{messages['label.languages']}"/>

Waarbij dit maar één enkele voorbeeld is.
Want de EL kan je in elk JSF / Custom component gebruiken. En met de XML files gaat dat niet meer.

Mocht je een ander framework of componenten gebruiken die niet JSF zijn dan kan je nogsteeds van de resource bundles gebruik maken. Dit gaat niet met XML.

(Struts / JSF en de Java Resource bundles maken allemaak gebruik van de key / value pair)

[JaWi]

Verwijderd schreef op vrijdag 20 mei 2005 @ 15:05:
[...]


Sorry ja, dat was iets te onduidelijk geformuleerd. Het idee is dat je voor elke tekst een lange (uitgebreide) tekst hebt en een kortere. Op de manier kan je je interface schakelen tussen eentje met veel tekst en eentje met weinig, die echter wel het zelfde betekenen.

Iets in de trend van:

Long: "Hallo meneer Bla u bevindt zich nu in het hoofscherm van onze mooie applicatie"
short: "U bent in het hoofdscherm"

Als ik vragen mag: wat heeft dat in hemelsnaam te maken met verschillende talen? Het voorbeeld doet mij denken aan een "dummy" vs. "expert" mode van je applicatie en zou in aparte resource bundles evengoed kunnen worden opgelost.
(Je wilt eventueel niet alles moeten vertalen? Prima, dan zet je de expert-bundle als default en laad je de dummy variant; gevolg is dat als een key niet in de dummy variant gevonden wordt, deze uit de expert-bundle gehaald wordt).

[FendtVario]

Ik denk dat de TS meer iets bedoelde als de volgende vertaling:
Undo Move Message
Ongedaan maken verplaatsen bericht

Nu is dit een voorbeeldje uit het Thunderbird menu, daar valt het probleem wel mee wat er staan verder geen controls in een menu. Op een panel is het misschien wel vervelend.

[Verwijderd]

JaWi schreef op vrijdag 20 mei 2005 @ 15:17:
[...]
Als ik vragen mag: wat heeft dat in hemelsnaam te maken met verschillende talen?

Opzich niet met de taal, maar wel met de teksten natuurlijk.

Het voorbeeld doet mij denken aan een "dummy" vs. "expert" mode van je applicatie en zou in aparte resource bundles evengoed kunnen worden opgelost.

Inderdaad. Ik gaf zelf ook al aan dat dat een optie is.

(Je wilt eventueel niet alles moeten vertalen? Prima, dan zet je de expert-bundle als default en laad je de dummy variant; gevolg is dat als een key niet in de dummy variant gevonden wordt, deze uit de expert-bundle gehaald wordt).

Dat is wel handig ja. Met resource bundles kan ik dus een hierarchy maken, en telkens als een key in de ene niet voorkomt pakt ie de bundle hoger in de hierarchy. Natuurlijk kan ik dat met het XML systeem ook doen. De code die de keys ophaalt kan ik ook zo schrijven dat als de short niet gevonden wordt ie meteen de long pakt.

[Verwijderd]

Ik zou het gewoon bij de standaard resource bundles houden.

<short> Hallo <outputText value="#{MyBean.name}" /> </short>

Gedeeltelijk draai je de zaken nu een beetje om: Je gaat feitelijk code (JSF/EL) in je resource bundle zetten. Dat lijkt me niet 'the way'. Je resource bundle moeten gewone pure strings zijn. Nu bouw je een dependency in voor in het algemeen JSF en in het bijzonder MyBean.

Handig als je je code gaan refactoren, mag je ook alle verwijzingen in je eigen formaat resource bundle meenemen. Daarbij komt dan dat je <outputText value="#{MyBean.name}" /> voor elke taal in je file hebt staan.

Jou oplossing heeft wel tot gevolg dat dit bijvoorbeeld niet meer gaat werken:

<f:loadBundle basename="mypackage.Messages" var="messages"/>

<h:outputLabel value="#{messages['label.languages']}"/>

Waarbij dit maar één enkele voorbeeld is.

Klopt ja, maar als TS gewoon een bean in scope heeft die de Map interface implementeed en die aan de hand van een key een string teruggeeft kun je opzich wel hetzelfde maken. Het lijkt me een beetje onzin allemaal, maar dat zou wel kunnen...

[ronaldmathies]

Hierbij mag de text dan ook taglib tags en EL bevatten. Bijvoorbeeld:
<short> Hallo <outputText value="#{MyBean.name}" /> </short>

Ik weet niet in hoeverre jij bekend bent met JSF maar het spontaan toevoegen en verwijderen van JSF componenten is niet toegestaan, hierdoor raakt je component tree corupt met als gevolg dat het renderen van je pagina zal mislukken.

Als je componenten in JSF wel of niet wilt laten renderen dan zal je dit met de rendered attribute moeten doen.

[Verwijderd]

ronaldmathies schreef op zaterdag 21 mei 2005 @ 12:16:
[...]
Ik weet niet in hoeverre jij bekend bent met JSF maar het spontaan toevoegen en verwijderen van JSF componenten is niet toegestaan, hierdoor raakt je component tree corupt met als gevolg dat het renderen van je pagina zal mislukken.

Daar ben ik wel van de op de hoogte. Het is inderdaad een puntje om rekening mee te houden dat het verschil tussen de korte en lange teksten nooit een JSF component mag zijn; dwz dat het JSF component er dus altijd staat.

[Verwijderd]

Zijn er nog meer mensen hier die een mening hebben over een eigen i18n systeem maken?

Ik twijfel nu toch wel om er nog mee door te gaan...