[PHP/alg.] OO en meertaligheid

[BikkelZ]

Als je een simpel PHP paginaatje maakt, trek je gewoon alle variabele taalvelden voor die taal uit de DB, gooit ze in een arraytje en parset het naar de pagina. Simpel.

Maar als je een redelijk complexe OO applicatie hebt, lijkt het al gauw complexer te worden. Zo genereert een object vaak exceptions. Die moet je dan abstract houden en dan pas rond parsing time omzetten naar de bijbehorende error in de juiste taal.

Ook dat is nog bij te houden.

Maar je kunt op een gegeven moment niet meer alle mogelijke foutmeldingen voor alle objecten voor die taal alvast inladen (zoals ik in een 'normaal' programma zou doen), dat wordt simpelweg te zwaar, zeker als je 90% van je classes maar 10% van de tijd gebruikt.

Hoe is dat het meest optimaal op te lossen?

[Confusion]

Begrijp ik goed dat je subclasses van een exceptie maakt voor iedere taal waarin de exceptie gegooid moet kunnen worden? In dat geval: dat is geen handige oplossing. Je kan gewoon de noodzakelijke errormessage uit de database (properties file) rukken op het moment dat die nodig is en tot die tijd voor iedere mogelijke exceptie slechts 1 klasse klaar hebben staan (die trouwens in bijvoorbeeld Java ook nog een lazy geladen wordt tot die echt nodig is).

Een exceptie op het moment dat die gegooid wordt vullen met de foutmessage in de juiste taal heeft niets met 'abstract houden' te maken. In bijvoorbeeld Java instantieer je exceptie objecten op het moment dat die gegooid worden en de klasse is dus zeker niet abstract.

Bovendien zijn dingen die niet gebruikt worden niet 'zwaar'. Klasse definities nemen nauwelijks geheugenruimte in. Applicaties met een paar duizend klassen behoren nog tot de kleine categorie.

[ Voor 34% gewijzigd door Confusion op 12-07-2007 14:52 ]

[Kalentum]

je vertalingen pas ophalen op het moment dat je ze nodig hebt: bij het renderen van de pagina.

Ik geloof dat gettext hier wel efficient mee omgaat.

[BikkelZ]

Tja heel concreet: ik zit nu met een 'Postcode onbekend' melding op een franstalige website op het moment dat je een verkeerde postcode invoert omdat dat nou eenmaal zo in de klasse Adres zit. Dus ik dacht, heel simpel, ik maak gewoon alle exceptions abstract met een nummer en ik laad gewoon alle foutmeldingen die nu in classes zitten in van te voren.

Dat werd best een lange lijst.

Maar misschien omdat het nu achteraf moet ( - "Euh oh en ja en euh heb je nog even een vertaling voor de Franse site?....") dat het ingewikkelder lijkt dan het is. Ik moet nu een grotere scheiding tussen de verschillende lagen gaan doen dan ik van te voren bedacht had terwijl als ik dat vooraf geweten had natuurlijk niet zo moeilijk zou zijn geweest: gewoon eerst alle fouten opsparen, die in een keer opzoeken, de boel parsen, en alle parse errors daarna nog een keer opzoeken en parsen.

[BikkelZ]

rutgerw schreef op donderdag 12 juli 2007 @ 14:51:
je vertalingen pas ophalen op het moment dat je ze nodig hebt: bij het renderen van de pagina.

Ik geloof dat gettext hier wel efficient mee omgaat.

gettext() lijkt me een goede, dan kan ik ook de errors als een text string laten staan.

Keerzijde is wel dat die language file erg lastig via CMS-achtige toestanden te editen is. Niets erger dan een communicatie medewerker die je steeds loopt te stalken omdat je weer ergens een " of , bent vergeten in een foutmelding in een applicatie

[Verwijderd]

Waarom is dat lastig? Je kunt er toch een frontend op maken die gebruiksvriendelijk is?

[BikkelZ]

Verwijderd schreef op donderdag 12 juli 2007 @ 15:11:
Waarom is dat lastig? Je kunt er toch een frontend op maken die gebruiksvriendelijk is?

Ja maar je moet toch de hele webservice opnieuw opstarten voordat de nieuwe .mo file in beeld komt?\

-------

Wel sneller dan een array met strings!:

http://mel.melaxis.com/de...n-is-gettext-fast-enough/

[ Voor 20% gewijzigd door BikkelZ op 12-07-2007 15:18 ]

[JKVA]

BikkelZ schreef op donderdag 12 juli 2007 @ 15:03:
[...]


gettext() lijkt me een goede, dan kan ik ook de errors als een text string laten staan.

Keerzijde is wel dat die language file erg lastig via CMS-achtige toestanden te editen is. Niets erger dan een communicatie medewerker die je steeds loopt te stalken omdat je weer ergens een " of , bent vergeten in een foutmelding in een applicatie

Toch is dat een vrij gangbare methode. Zie Java. Daar heb je de klasse ResourceBundle, welke niets meer is dan een object weerspiegeling van een properties file, ofwel een file met key-value paren. De key is jouw interne dataformaat (ik zou wel adviseren deze keys een beetje leesbaar te houden, dus geen errorcodes, maar een soort tekst, want dan kun je ze zonder vertaling herkennen). Value is de taal specifieke tekst.

Voor elke taal maak je een dergelijk bestand en afhankelijk van de Locale settings van de client (accept-locale http header o.i.d. weet niet meer precies) laad je een ander bestand in. Eventueel pas je hier lazy loading/caching toe.

Als je met een database werkt, hanteer je in feite hetzelfde principe, behalve dat een database stukken flexibeler is en je er een soort CRUD functionaliteit omheen kunt bouwen voor beheer van de meldingen. Een beetje customizable CMS moet dat toch wel kunnen neem ik aan.