[Java] Hoe het beste multi-language te implementeren

[Twazerty]

Zit al uren te proberen hoe ik het beste multi-language in kan bouwen en kom er niet echt uit wat nu de handigste/beste manier is.
Dit is mijn eerste idee maar volgens mij moet dat toch beter kunnen:
Aparte klasse Taalinhoud.
Voor iedere button/label etc maak ik een array. De lengte van het array zijn het aantal talen.
Vervolgens ga ik elke array setten. Word dus enorm veel code en zie niet direct hoe ik nu die tekst in mijn GUI zet. Worden weer enorm veel sets en gets. Voor iedere button een get die aangeroepen word vanuit de gui. Vb:
button1.setText(taalinhoud.getButton1Text());

Tweede idee:
Voor iedere taal maak ik een array waarbij iedere waarde in het array een tekst is voor de buttons. Volgende waarde volgende button.
Nu gaat het ophalen van de tekst door middel van een switch statement. Vanuit de gui telkens dezelfde aanroep alleen dan met een andere int waarde. Lijkt me effectiever als mijn eerste idee maar volgens mij raak je nu een beetje het overzicht kwijt. Krijg je niet meer te zien als button1.setText(taalinhoud.getTaaltext(1)); enz.

En daar raken mijn ideen op. Beide manieren hebben voor en nadelen. De eerste zodat je meer overzicht hebt (Denk ik) en de tweede scheelt code maar lijk me niet duidelijke en een fout is er makkelijker gemaakt?

Wie kan me helpen de beste manier te vinden. Wellicht de tekst in een externe file ipv hardcoded. Hoe pakken jullie zoiets aan? Wat kan ik het beste doen?

[krvabo]

Voor je eerste idee kun je het state pattern gebruiken.
Je maakt dan voor elke taal inderdaad een aparte klasse, waarin je bijvoorbeeld een array of een hashmap kunt gebruiken.
Ik heb dit pattern iig al een keer gebruikt om miltilanguage te implementeren.

Eventueel zou je ook nog dmv een builder of factory pattern dynamisch de objecten kunnen maken uit textfiles.

[Anoniem: 281802]

Is je applicatie voorzien van een database, of is het mogelijk die aan je applicatie toe te voegen?

Wat wij doen is afhankelijk van de taalinstelling van de gebruiker een titel bijlezen uit de database uit een titeltabel. Erg simpel en doeltreffend.

[matthijsln]

Je gebruikt hiervoor natuurlijk gewoon de features die Java (of welke andere ontwikkelomgeving dan ook) je hier hier voor biedt. De ontwikkelaars van Java hebben hier natuurlijk al wel over nagedacht.

Zie voor Java de Java Tutorial, internationalization trail: http://java.sun.com/docs/books/tutorial/i18n/index.html

Wat je inderdaad goed hebt in je post is dat je eerste twee ideeën nogal wat nadelen hebben en dat wordt normaliter inderdaad opgelost door tekst in een extern bestand te plaatsen. Het Java framework heeft daar al een boel code voor geimplementeerd zodat je dat zelf niet meer hoeft te doen. In je eigen code hoef je dan verder praktisch geen extra code per stukje gelocaliseerde tekst toe te voegen.

[Phyxion]

krvabo schreef op vrijdag 13 februari 2009 @ 02:33:
Voor je eerste idee kun je het state pattern gebruiken.
Je maakt dan voor elke taal inderdaad een aparte klasse, waarin je bijvoorbeeld een array of een hashmap kunt gebruiken.
Ik heb dit pattern iig al een keer gebruikt om miltilanguage te implementeren.

Eventueel zou je ook nog dmv een builder of factory pattern dynamisch de objecten kunnen maken uit textfiles.

Heeft als nadeel dat je niet zo makkelijk nieuwe talen toe kan voegen.

[Remus]

Ik sluit mij bij matthijsIn aan: gebruik de i18n features die al in Java zijn ingebouwd en ga niet het wiel opnieuw uitvinden. De i18n en L10n in Java zijn zeer uitgebreid en zeer bruikbaar.

[Teeno]

Ik heb hier zelf ook eens over na zitten denken, en waar ik op uitkwam is het volgende.

In je projectmap een aparte map languages maken met daarin voor elke taal een bestand op basis van xml-tags. Aan de hand van een lokaal settings bestand kan men het taalbestand selecteren. dat bestand gooi je door een xml-parser en haal de regel eruit die je nodig hebt. Voordeel hiervan is dat je makkelijk extra talen kan toevoegen/aanbieden als download, nadeel echter dat je niet het programma kan uitbreiden zonder al je taalbestanden mee te nemen.

[Macros]

Ik sluit me bij Remus en matthijsln aan. Gebruik de ResouceBundle frameworks van Java zelf. Die bestaat uit een aantal properties file, 1 per taal met 1 default file. Daarin staan key value paren. Die kan Java voor je inlezen en in een Map<String, String> map zetten. In je code refereer je voortaan altijd naar je keys, en die haal je uit de resoucebundle die tijdens het opstarten is geladen, welke afhankelijk is van de Locale die ingesteld staat of die de gebruiker zelf kan kiezen.

[Wijnbo]

Teeno schreef op vrijdag 13 februari 2009 @ 11:39:
Ik heb hier zelf ook eens over na zitten denken, en waar ik op uitkwam is het volgende.

In je projectmap een aparte map languages maken met daarin voor elke taal een bestand op basis van xml-tags. Aan de hand van een lokaal settings bestand kan men het taalbestand selecteren. dat bestand gooi je door een xml-parser en haal de regel eruit die je nodig hebt. Voordeel hiervan is dat je makkelijk extra talen kan toevoegen/aanbieden als download, nadeel echter dat je niet het programma kan uitbreiden zonder al je taalbestanden mee te nemen.

Wat bedoel je al je taalbestanden meenemen? Als je een nieuwe string ergens nodig hebt dan is het volgens mij vrij logisch dat je ook een nieuwe vertaling er bij moet maken.

Kijk hier eens naar : http://java.sun.com/j2se/...api/java/util/Locale.html

[flowerp]

Macros schreef op vrijdag 13 februari 2009 @ 12:08:
Ik sluit me bij Remus en matthijsln aan. Gebruik de ResouceBundle frameworks van Java zelf.

Ik sluit me volledig aan bij Remus, matthijsln en Macros.

Zelf je eigen i18n implementatie gaan zitten maken is een ernstige vorm van het NIH syndrome (zie Wikipedia: Not Invented Here). Tenzij je zelf een library maker bent en je volledige focus is om een alternatieve i18n implementatie te maken (en dan nog!), moet je het gewoon niet doen.

Dikwijls zie je dat mensen het wiel ook telkens overniew uitvinden om de volgende redenen:

1) Ze weten gewoon niet dat het wiel al bestaat (dat heeft dit topic nu opgelost )
2) Er heerst de perceptie dat zelf maken minder moeite kost dan het bestaande leren/doorgronden.

1) is dus al opgelost en over 2) kan ik kort zijn: Java's std i18n leren is eenvoudig en zelfbouw gaat uiteindelijk meer tijd kosten en vooral irritatie mochten er ooit andere mensen mee gaan programmeren.

[Twazerty]

flowerp schreef op zaterdag 14 februari 2009 @ 13:57:
[...]


Ik sluit me volledig aan bij Remus, matthijsln en Macros.

Zelf je eigen i18n implementatie gaan zitten maken is een ernstige vorm van het NIH syndrome (zie Wikipedia: Not Invented Here). Tenzij je zelf een library maker bent en je volledige focus is om een alternatieve i18n implementatie te maken (en dan nog!), moet je het gewoon niet doen.

Dikwijls zie je dat mensen het wiel ook telkens overniew uitvinden om de volgende redenen:

1) Ze weten gewoon niet dat het wiel al bestaat (dat heeft dit topic nu opgelost )
2) Er heerst de perceptie dat zelf maken minder moeite kost dan het bestaande leren/doorgronden.

1) is dus al opgelost en over 2) kan ik kort zijn: Java's std i18n leren is eenvoudig en zelfbouw gaat uiteindelijk meer tijd kosten en vooral irritatie mochten er ooit andere mensen mee gaan programmeren.

Je hebt volledig gelijk. Ik wist idd niet dat zoiets al bestond. Maar ik heb nu wel iets geleerd. Dat sommige dingen gewoon bijna niet te doen zijn. Ik heb een stukje gelezen van de gegeven link. Aan de ene kant ziet het er simpel uit en aan de andere kant snap ik het nog niet helemaal. Maar dat komt omdat ik het nog niet geprobeerd heb en niet alles gelezen heb. Mocht ik er niet uitkomen dan meld ik dat hier wel in de hoop dat jullie kunnen helpen

[Marv]

flowerp schreef op zaterdag 14 februari 2009 @ 13:57:
Dikwijls zie je dat mensen het wiel ook telkens overniew uitvinden om de volgende redenen:

1) Ze weten gewoon niet dat het wiel al bestaat (dat heeft dit topic nu opgelost )
2) Er heerst de perceptie dat zelf maken minder moeite kost dan het bestaande leren/doorgronden.

3) Ze willen leren hoe je een functioneel/mooi wiel maakt

Leuk om te doen, mits je er de tijd voor hebt. Wil je het gebruiken voor een belangrijk systeem (dus niet je eigen hobby project ), neem dan in godsnaam een standaard library.
Ben je zelf lekker aan 't hobby'en en zit je niet vast aan tijd en een budget... en lijkt het je leuk om zelf iets te bouwen.... why not, kan alleen maar leerzaam zijn

Je kan het altijd nog vervangen door een standaard component.

[FendtVario]

Nu het er toch over gaat; heeft iemand wel eens poging gedaan om multi-language ook op een fatsoenlijke manier te implementeren voor je applicatie data. Als je kijk naar een gemiddelde applicatie zijn er vaak maar een paar tabellen waarvoor je meertalige omschrijvingen wilt kunnen vastleggen (bijv. productnamen, print document namen, of misschien zelfs adressen, in Nederlands en Frans voor België).

Ik ken oplossingen die een tekst tabel maken met de volgende velden:
tabelnaam, veldnaam, primaire sleutelwaarde, taalcode, tekst

Vervolgens is er ergens een stukje code dat uit deze tabel de juiste omschrijving haalt. Database technisch niet echt netjes want in de kolom 'primarie sleutelwaarde' staan uit verschillende tabellen sleutelwaarden dus tot zo ver referentiële integriteit. Ik zit zelf te denken aan een aparte type; MultiLingualString ofzo, die op basis van de getDefautLocale de juiste string terug geeft.

[momania]

Uhm heb je de rest van het topic wel gelezen en dan vooral ook de tutorial achter deze link: http://java.sun.com/docs/books/tutorial/i18n/index.html

[Morax]

momania schreef op dinsdag 17 februari 2009 @ 07:54:
Uhm heb je de rest van het topic wel gelezen en dan vooral ook de tutorial achter deze link: http://java.sun.com/docs/books/tutorial/i18n/index.html

FendtVario vraagt of er een fatsoenlijke implementatie bestaat om de data in je database te internationaliseren, wat ik ondanks de tutorial toch een valide vraag vind

De link verteld vooral hoe je data internationaliseert die normaal gesproken hard in je applicatie staan. Maar hoe internationaliseer je de data in een tabel in je database? Ga je voor elke regel in je databasetabel dan een *.properties file bijwerken met een nieuwe key => value pair en opsturen naar je klanten??

[momania]

Morax schreef op dinsdag 17 februari 2009 @ 08:44:
[...]


FendtVario vraagt of er een fatsoenlijke implementatie bestaat om de data in je database te internationaliseren, wat ik ondanks de tutorial toch een valide vraag vind

Je eigen resource bundle implementeren die gegevens uit een database haalt
Als basis heb je maar 3 of 4 kolomen nodig: locale, (of opgesplitst in land en taal), property, value

Zaken als adressen zijn niet multi-language. Je heb alleen verschillende formats per land.

[Gerco]

momania schreef op dinsdag 17 februari 2009 @ 08:57:
Zaken als adressen zijn niet multi-language. Je heb alleen verschillende formats per land.

Nee, maar dingen als namen van producten wel. Dan kom je er niet met een simpele key-value mapping, want je weet de key van tevoren niet (elk product heeft immers zijn eigen vertaling).

Dan kun je natuurlijk wel al die vertalingen in 1 tabel gooien (table, pk, field, locale, text) oid, maar dan heb je dus data over meerdere verschillende entiteiten in 1 tabel staan. Wat me overigens geen probleem lijkt met bovenstaande tabel, gewoon de PK op table, pk, field leggen. Vereist natuurlijk wel dat je enkelvoudige primary keys hebt in je product tabel en alle andere tabellen die je zo wilt behandelen, maar dat lijkt me sowieso geen slecht idee

[momania]

Gerco schreef op dinsdag 17 februari 2009 @ 09:11:
[...]
Nee, maar dingen als namen van producten wel.

Namen van producten zijn meestal een combinatie van het merk + een type. imo dus ook niet multi-language

Product categorieën en beschrijvingen van producten kunnen dan weer wel multi-language zijn

[Face_-_LeSS]

momania schreef op dinsdag 17 februari 2009 @ 08:57:
[...]

Je eigen resource bundle implementeren die gegevens uit een database haalt
Als basis heb je maar 3 of 4 kolomen nodig: locale, (of opgesplitst in land en taal), property, value

Dat is inderdaad een oplossing, maar waar ik tegenaan liep (in .NET weliswaar) is de sortering op vertaalde kolommen. De vertaalslag zou moeten gebeuren voor het sorteren maar omdat de vertaling pas plaatsvindt op de op het moment dat de data uit de database is gehaald zal er na het vertalen gesorteerd moeten worden in code i.p.v. op database niveau. En eigenlijk wil je dat niet.

[Herko_ter_Horst]

momania schreef op dinsdag 17 februari 2009 @ 09:56:
[...]Namen van producten zijn meestal een combinatie van het merk + een type. imo dus ook niet multi-language

Ja, daarom heet de Canon 450D hier ook 450D en in de VS de Canon Digital Rebel XSi

Je zult versteld staan van hoeveel er "in het echt" locale-afhankelijk is, van namen en typenummers tot kleuren en foto's aan toe.

Kijk voor de gein alleen al eens naar de verschillen tussen de US en de UK versie van de productpagina van deze camera (zelfde bedrijf, zelfde camera, "zelfde" taal):

http://www.usa.canon.com/...egoryid=139&modelid=16303
http://www.canon.co.uk/fo...al_slr/eos_450d/index.asp

[ Voor 27% gewijzigd door Herko_ter_Horst op 17-02-2009 11:26 ]

[momania]

Herko_ter_Horst schreef op dinsdag 17 februari 2009 @ 11:22:
[...]

Ja, daarom heet de Canon 450D hier ook 450D en in de VS de Canon Digital Rebel XSi

Technisch zijn het dezelfde camera's, maar eigenlijk gewoon 2 verschillende types.
Zo zijn er wel meer producten die eigenlijk hetzelfde zijn maar per land of zelfs merk van naam/type verschillen(denk aan verschillende automerken die dezelfde type met een ander label verkopen)

In een stuk software of database zijn dat imo gewoon verschillende items.

Hier heb je geen localization nodig, maar verschillende producten sets per land/merk/etc.

[bomberboy]

Face_-_LeSS schreef op dinsdag 17 februari 2009 @ 10:42:
[...]
Dat is inderdaad een oplossing, maar waar ik tegenaan liep (in .NET weliswaar) is de sortering op vertaalde kolommen. De vertaalslag zou moeten gebeuren voor het sorteren maar omdat de vertaling pas plaatsvindt op de op het moment dat de data uit de database is gehaald zal er na het vertalen gesorteerd moeten worden in code i.p.v. op database niveau. En eigenlijk wil je dat niet.

Waarom zou dat sorteren dan in de applicatie moeten gebeuren? Ofwel begrijp ik de opmerking van momania niet goed, maar bij een implementatie van die resourcebundle die data uit een db haalt zie ik dat als volgt:

nu heb je bijvoorbeeld iets als:
1.A) id | somedata | somedata | taalafhankelijke beschrijving
En dit vervang je door iets als
2.A) id | somedata | somedata | id van beschrijving
2.B) id van beschrijving | eigenlijke beschrijving

dus enkel een id van de beschrijving in de originele tabel, en dan per taal een vertaalde beschrijving.

In je applicatie is je query dan een join van die beide tabellen. Of definieer desnoods een view van die join voor elke mogelijke taal, dan moet je applicatie er zich helemaal niets van aantrekken en zit het allemaal op DB-niveau.

Indien je vertalingen niet allemaal compleet zijn, of je wil terugvallen op een default-taal, dan kan je in tabel 2.A eventueel de default beschrijving ook laten staan en het id voor andere talen.

Daar kan je dan op applicatieniveau dan wel rekening mee houden. (Of misschien kan je dit in SQL ook direct vervangen op db-niveau, daarvoor ben ik niet goed genoeg met SQL).

Het komt er gewoon op aan van elke mogelijke tekstuele beschrijving niet als tekst in je tabel te stoppen, maar te koppelen aan een externe key die de vertaling geeft. Dan is het gewoon een join op de juiste tabellen.
Eigenlijk is dit identiek aan wat in die internationalisation van Java gebeurt.

[Face_-_LeSS]

bomberboy schreef op dinsdag 17 februari 2009 @ 12:47:
[...]


Waarom zou dat sorteren dan in de applicatie moeten gebeuren? Ofwel begrijp ik de opmerking van momania niet goed, maar bij een implementatie van die resourcebundle die data uit een db haalt zie ik dat als volgt:

nu heb je bijvoorbeeld iets als:
1.A) id | somedata | somedata | taalafhankelijke beschrijving
En dit vervang je door iets als
2.A) id | somedata | somedata | id van beschrijving
2.B) id van beschrijving | eigenlijke beschrijving

dus enkel een id van de beschrijving in de originele tabel, en dan per taal een vertaalde beschrijving.

In je applicatie is je query dan een join van die beide tabellen. Of definieer desnoods een view van die join voor elke mogelijke taal, dan moet je applicatie er zich helemaal niets van aantrekken en zit het allemaal op DB-niveau.

Indien je vertalingen niet allemaal compleet zijn, of je wil terugvallen op een default-taal, dan kan je in tabel 2.A eventueel de default beschrijving ook laten staan en het id voor andere talen.

Daar kan je dan op applicatieniveau dan wel rekening mee houden. (Of misschien kan je dit in SQL ook direct vervangen op db-niveau, daarvoor ben ik niet goed genoeg met SQL).

Het komt er gewoon op aan van elke mogelijke tekstuele beschrijving niet als tekst in je tabel te stoppen, maar te koppelen aan een externe key die de vertaling geeft. Dan is het gewoon een join op de juiste tabellen.
Eigenlijk is dit identiek aan wat in die internationalisation van Java gebeurt.

Waarschijnlijk weet jij niet dat een 'ResourceBundle' een Java klasse is. Ik ken de klasse verder ook niet, maar na het lezen van de beschrijving is het volgens mij vrijwel het zelfde als een ResourceManager in .NET. Dat wil zeggen, een instantie van de ResourceBundle klasse is eigenlijk gewoon een soort dictionary (Label -> vertaling) welke gevuld wordt met locale afhankelijke inhoud.
Van deze klasse kan je uiteraard zelf een implementatie maken die dan data uit bijvoorbeeld een SQL tabel haalt, maar dan vind de vertaling nog steeds "in-code' plaats wat gevolgen kan hebben op de sortering van resultaten.

[bomberboy]

Face_-_LeSS schreef op dinsdag 17 februari 2009 @ 14:43:
[...]
Waarschijnlijk weet jij niet dat een 'ResourceBundle' een Java klasse is. Ik ken de klasse verder ook niet, maar na het lezen van de beschrijving is het volgens mij vrijwel het zelfde als een ResourceManager in .NET. Dat wil zeggen, een instantie van de ResourceBundle klasse is eigenlijk gewoon een soort dictionary (Label -> vertaling) welke gevuld wordt met locale afhankelijke inhoud.

Ik ben vertouwd met hoe het in Java werkt hoor

Van deze klasse kan je uiteraard zelf een implementatie maken die dan data uit bijvoorbeeld een SQL tabel haalt, maar dan vind de vertaling nog steeds "in-code' plaats wat gevolgen kan hebben op de sortering van resultaten.

Over welke sortering heb je het eigenlijk, want ik denk dat ik dan eerder de vraag verkeerd begrijp.
Als je sorteert op het tekstveld (dat verschillend is per taal) zal de sortering er uiteraard altijd anders uitzien natuurlijk.

Maar met de oplossing die ik gaf kan je:
De aplicatie-logica ongemoeid laten indien je een nieuwe view definieert voor elke taal (dus een join op de tabel met nuttige data en dan de tabel met vertaling van beschrijvingen).
Dan kan je zonder problemen sorteren of wat dan ook op de databank en blijft de implementatie logica exact hetzelfde. (Uiteraard moeten de tabelnamen ergens ingesteld worden, maar als je de locale of taal al ergens detecteert of aan de gebruiker vraagt kan je ook die tabelnaam configureerbaar maken)

Indien je het zonder die views doet dan moet je idd in je code zelf ergens de juiste join gaan doen, en dat is dan exact hetzelfde zoals dat je in java van die ResourceBundle gebruik gaat maken. Maar nog steeds kan je dan sorteren en gelijk welke operatie direct op de databank doen.

Kan je dus even verduidelijken waar ik volgens jou de mist in ga?

edit:
Indien het gaat om letterlijk die ResourceBundle implementeren dan is het inderdaad niet helemaal hetzelfde. Maar ik doelde op het concept dat heel gelijkaardig is aan het gebruik van een ResourceBundle

[ Voor 5% gewijzigd door bomberboy op 17-02-2009 22:06 ]

[FendtVario]

momania schreef op dinsdag 17 februari 2009 @ 08:57:
[...]
Zaken als adressen zijn niet multi-language. Je heb alleen verschillende formats per land.

Niet helemaal waar. Bij onze zuiderburen, België, kan een straat of plaats twee namen hebben. Een in het Nederlands, de andere in het Frans. Zelfs in Friesland zou dit met plaatsnamen kunnen . Dus niet alleen het format verschilt, Maar laten we de discussie over wat wel/niet meertalig moet stoppen. Ik denk dat het idee duidelijk is.

bomberboy schreef op dinsdag 17 februari 2009 @ 12:47:
Waarom zou dat sorteren dan in de applicatie moeten gebeuren? Ofwel begrijp ik de opmerking van momania niet goed, maar bij een implementatie van die resourcebundle die data uit een db haalt zie ik dat als volgt:

nu heb je bijvoorbeeld iets als:
1.A) id | somedata | somedata | taalafhankelijke beschrijving
En dit vervang je door iets als
2.A) id | somedata | somedata | id van beschrijving
2.B) id van beschrijving | eigenlijke beschrijving

dus enkel een id van de beschrijving in de originele tabel, en dan per taal een vertaalde beschrijving.

[...]

Dit zou inderdaad ook kunnen, maar ik zie niet helemaal wat je in 2a en 2b 'id van de beschrijving' wilt. Ik ga er vanuit dat 2a en 2b een 1-op-veel relatie hebben, maar dan neem je de 1-kant op aan de veel-kant. Dus wat doet 'id van de omschrijving'.

Verder is het idee van ResourceBundles wel interessant, maar hoe ga je in de database je referenties vast leggen. Ik zou graag een oplossing hebben die ook de database referenties houdt zoals ze horen.

Zelf neig ik naar een oplossing die lijkt op die van bomberboy maar net even anders. Multilanguage implementeren in twee tabellen (even niet letten op de tabelnamen):

Tabel 1: multilanguage_strings ( id, tabelnaam, veldnaam, lengte )
Tabel 2: multilanguage_values (id, pkey_tabel1, locale, waarde )

vervolgens bijv. de tabel producten:
producten (id, productnummer, etc ..... etc, description_id)
waarbij description_id verwijst naar de pkey van tabel 1.

Voordeel, database referenties zijn intact (dus ook je cascade operaties), direct prikken op vetraling door link naar pkey. Het record in 'tabel 1' wordt in principe eenmaling aangemaakt en is daarna een soort tussentabel tussen 'product' en de vertaling. De velden tabelnaam, veldnaam zijn puur informatief. Nadeel, ja verzin maar, ik zie er ff geen.

[Alain]

Ik heb hier ook over nagedacht en ik vind een database gebruiken nogal een rare oplossing. Een vertaling is niet bepaald dynamisch. Ik denk er aan om gettext te gaan gebruiken. Ik ben er zelf nog niet aan toe, maar een snelle zoektocht leverde dit op: http://www.pdfsam.org/jav...i18n/GettextResource.html

[Face_-_LeSS]

bomberboy schreef op dinsdag 17 februari 2009 @ 12:47:
[...], maar bij een implementatie van die resourcebundle die data uit een db haalt zie ik dat als volgt:

[...]

Vandaar dat ik even dacht dat je niet wist dat het om een klasse ging.

bomberboy schreef op dinsdag 17 februari 2009 @ 14:59:
edit:
Indien het gaat om letterlijk die ResourceBundle implementeren dan is het inderdaad niet helemaal hetzelfde. Maar ik doelde op het concept dat heel gelijkaardig is aan het gebruik van een ResourceBundle

Misverstand opgelost dus


Wanneer je inderdaad op database-niveau de juiste vertaling opzoekt dan komt de sortering niet in de knoei.

[FendtVario]

AlainS schreef op woensdag 18 februari 2009 @ 03:06:
Ik heb hier ook over nagedacht en ik vind een database gebruiken nogal een rare oplossing. Een vertaling is niet bepaald dynamisch. Ik denk er aan om gettext te gaan gebruiken. Ik ben er zelf nog niet aan toe, maar een snelle zoektocht leverde dit op: http://www.pdfsam.org/jav...i18n/GettextResource.html

Veel gegevens in een database zijn ook niet bepaald dynamisch. Ingegeven orders worden ook niet vaak meer veranderd (er komt wel wat data bij natuurlijk), er worden wel steeds nieuwe aangemaakt. De vertalingen zullen voor bedoelt zijn (voor wat ik noem) semi-statische data. Productnamen dus, deze worden wel bijgemaakt of verwijderd maar zullen niet echt vaak veranderen. Denk eraan, het is ook gewoon data die door een gebruiker van de software wordt ingegeven.

De gettext methode vind ik niet echt geschikt omdat de meeste implementaties uitgaan van een functie aanroep met de standaard tekst. Niet echt geschikt als ook de standaard tekst (die van de standaard taal) ergens in de database staat. Ik ga nog eens proberen met mijn MultiLanguageString idee.

Het verbasst me overigens wel een klein beetje dat het erop lijkt dat er voor dit soort problemen niet echt een standaard oplossings methode is.

[Alain]

FendtVario schreef op woensdag 18 februari 2009 @ 21:38:
[...]


Ingegeven orders worden ook niet vaak meer veranderd (er komt wel wat data bij natuurlijk), er worden wel steeds nieuwe aangemaakt.

Een ingegeven order zal ook niet vaak bevraagd worden. Een vertaling zal vaker bevraagd worden.

Ik zeg ook niet dat gettext ideaal is, sterker nog: ik heb het nog niet geprobeerd. Ik heb alleen nog maar nagedacht over multi language en dit was mijn gedachte. Ik heb alleen wat tussendoorklusjes die mij weerhouden van het uit te proberen.

[FendtVario]

Ja, als er nou eens iets meer uren in een dag zaten he

[Gomez12]

AlainS schreef op woensdag 18 februari 2009 @ 22:07:
[...]


Een ingegeven order zal ook niet vaak bevraagd worden. Een vertaling zal vaker bevraagd worden.

Ik zeg ook niet dat gettext ideaal is, sterker nog: ik heb het nog niet geprobeerd. Ik heb alleen nog maar nagedacht over multi language en dit was mijn gedachte. Ik heb alleen wat tussendoorklusjes die mij weerhouden van het uit te proberen.

Tipje van de sluier alvast, gettext is een goede oplossing voor statische dingen als een UI etc. niet voor user generated content ( en een artikelomschrijving is user generated in de meeste systemen )

En aan het einde van de rit is er meer user generated als je denkt, ongeveer alles wat er in de dbase staat...

[Twazerty]

Heb even zitten spelen en het is inderdaad erg simpel. Toch heb ik een probleem. Namelijk dat de tekst niet word veranderd. Wat ik wil is dat zodra ik op een knop druk de taal veranderd in mijn GUI. Deze code word uitgevoerd als ik op een knop druk:

Java:

        this.language = language;
        this.country = country;
        currentLocale = new Locale(language, country);
        messages = ResourceBundle.getBundle("AVCHDBitrateCalc/MessagesBundle",currentLocale);

Zo heb ik een bepaald label ingesteld. Zodat hij de juiste waarde pakt:


dat werkt opzich. Alleen als ik nu op een knop druk gebeurt er niks. Volgens mij vrij logisch want ik vertel niemand dat die label is veranderd. Mijn probleem is hoe ik dit werkend krijg. Als ik het volgende in de uigevoerde code zet werkt het logischerwijs wel:
stap1jLabelStap1.setText(messages.getString("step1"));

Maar dit lijkt me niet helemaal de juiste manier? Kan dat niet makkelijker? Ik zou iig niet weten hoe. Als ik dit in mijn GUI aanroep werkt het ook niet: setLocale(currentLocale);

[Erik Jan]

Je kan een interface LocaleChangeListener definiëren die je je GUI componenten laat implementeren.

Dan laat je elk component zich aanmelden bij de klasse die je locale veranderingen beheert.

Bij een verandering van locale gaat die dan alle listeners langs.

[Elvis]

Erik Jan schreef op woensdag 25 februari 2009 @ 00:42:
Je kan een interface LocaleChangeListener definiëren die je je GUI componenten laat implementeren.

Dan laat je elk component zich aanmelden bij de klasse die je locale veranderingen beheert.

Bij een verandering van locale gaat die dan alle listeners langs.

You lost me...
Kan je hier wat meer info over verschaffen?

PS: kan/is de klasse die de locale veranderingen beheert dezelfde zijn als die de GUI componenten beheert? Want daar staan toch de buttons met de verschillende taalkeuzes?
Of sla ik de bal helemaal mis?

[ Voor 19% gewijzigd door Elvis op 01-03-2009 23:10 ]

[Erik Jan]

Sorry voor de vertraging.

Een GUI component weet zelf het beste hoe hij aangepast moet gaan worden bij een locale update, dus de implementatie hiervan breng je in de klasse zelf onder, niet ergens extern.

Omdat er waarschijnlijk allerlei verschillende GUI componenten zijn, elk met een eigen klasse, en wellicht ook nog meer zaken die de locale moeten gaan bijhouden, moet er een soort afspraak komen hoe de verandering van locale dan wordt doorgegeven: een interface.

Dit kan geheel in stijl van Java + Swing/AWT met een listener, zodat de rest van de wereld ook snel kan begrijpen waar je mee bezig bent.

Concreet dus zoiets (uiteraard pseudo):

Java:

interface LocaleChangeListener {
    public void localeChanged(LocaleChangeEvent e);
}

class EenButton implements LocaleChangeListener {
    public EenButton(GUIContext c) {
        c.localeManager.addLocaleChangeListener(this);
    }
    public void localeChanged(LocaleChangeEvent e) {
        setText(Resource.getText("OK_TEXT", e.lang));
        if (e.lang == Language.GREEK)
            setSize(200, 300);
        // eventuele andere zaken
    }
}

class LocaleManager {
    Collection listeners;
    public void setLocale(Language to) {
        LocaleChangeEvent e;
        for (l : listeners)
            l.localeChanged(e);
    }
    public void addLocaleChangeListener(LocaleChangeListener l) {
        listeners.add(l);
    }
}

Denk ook aan andere zaken zoals datumnotatie, geldeenheid, rechts naar links fonts, wat allemaal bij "i18n" komt kijken.