[PHP] Taalmodules; opzet en efficientie

[Enlightenment]

Ik ben voor mijn CMS bezig om taalmodules te introduceren. Ik vraag me af hoe dat het beste kan. Ik had de volgende twee mogelijkheden in gedachte:

Plan 1: arrays
Ik maak een .php file met allemaal arrays erin, waarbij elke array een taalmodule is, zoals:

$lang['nl'][1] = 'Dit is de Nederlandse tekst voor item 1';
$lang['nl'][2] = 'Dit is de Nederlandse tekst voor item 2';
$lang['nl'][3] = 'Dit is de Nederlandse tekst voor item 3';
$lang['en'][1] = 'This is the English text for item 1';
$lang['en'][2] = 'This is the English text for item 2';
$lang['en'][3] = 'This is the English text for item 3';

Ik gebruik dan ipv hardcoded engelse tekst: $lang['nl'][26]. Elk nummer is dan gereserveerd voor een bepaalde tekst ergens gebruikt in mijn scripts.

Plan 2: functies
Ik maak een functie, die vervolgens de juiste tekst retourneert. Het voordeel hiervan zou zijn dat ik geen array heb met ALLE tekst, ook al gebruik ik maar b.v. 10 zinnen, alle 3000 zinnen (ik noem maar wat) moet hij dan wel inladen, wat wellicht veel geheugen kost.


Mijn vraag: wat lijkt jullie het meest efficient, en hebben jullie nog andere tips om taalmodules te implementeren? Het gaat dus om het design hiervan, ik wil vooraf de juiste keuzes maken.

$lang['text'] = "dit is een text";
$lang['blub'] = "dit is een vis";

En dan met aparte taalbestanden werken (1 taal = bestand).
Dan heb je ook geen shitload aan vars die je niet gebruikt omdat het een andere taal is (gezien dit erg hard kan oplopen).

Of als osCommerce het doet:
1 globale taal bestand per taal.
Met een directory waar voor ieder bestand weer een apart taalbestand is.
www.domein.tld/fiets.php roept dan taalbestand /languages/nl/fiets.php aan oid.

[Enlightenment]

Mijn CMS zit iets anders in elkaar.
Er staan b.v. helemaal geen bestanden in de documentroot.

Wat betreft $lang['blub'], dan ga je toch weer namen verzinnen en dat moet je allemaal bijhouden, of dat makkelijker is dan nummers? Ik dacht zelf overigens aan $lang[<modulenaam>][1], dus per module/plugin/corefunctie/pagina heb je een array.

De grote vraag is of een shitload aan vars dus niet voor een hoge overhead zorgt, ook al beperk je je tot 1 taal per file. Is het niet efficienter om een functie te gebruiken die somehow alleen de text teruggeeft die nodig is? Zit zelf nog wat te brainstormen hierover.

[Marcade]

Enlightenment schreef op 16-07-2005 @ 18:31 :
Mijn CMS zit iets anders in elkaar.
Er staan b.v. helemaal geen bestanden in de documentroot.

Wat betreft $lang['blub'], dan ga je toch weer namen verzinnen en dat moet je allemaal bijhouden, of dat makkelijker is dan nummers? Ik dacht zelf overigens aan $lang[<modulenaam>][1], dus per module/plugin/corefunctie/pagina heb je een array.

En hoe moet het dan met met cross-modulaire verwijzingen; neem aan dat je niet meerdere elementen wil reserveren voor hetzelfde woord.

Wat wij doen is een combinatie van nummers en modulenamen; waarbij we 1 generieke modulenaam hebben. Oftewel IF10001, IF10002, IM10001, PM10001, etc. Daarnaast hebben we de ranges verdeeld, waarbij bv. alles tussen 10000 en 30000 informatie is, 30000-40000 warning's en 40000 en daarboven errors. Om het extra duidelijk te maken, plaatsen wij er ook nog een W of een E achter, als 't om een warning of error gaat.

De grote vraag is of een shitload aan vars dus niet voor een hoge overhead zorgt, ook al beperk je je tot 1 taal per file. Is het niet efficienter om een functie te gebruiken die somehow alleen de text teruggeeft die nodig is? Zit zelf nog wat te brainstormen hierover.

Die functie moet de vertaling toch ook ergens vandaan halen; uit een array, of uit een file? Als ik moest kiezen tussen het continue lezen van een taalfile of een array; kies ik voor 't laatste. Een functie die een string teruggeeft moet snel werken sinds het vaak aangeroepen word.

[edit] Daarbij wel dus dat de array gevuld word dmv. een taal specifieke file (bv. een .csv file; lekker makkelijk icm. Excel) . Taal hardcoderen in de code zelf zie ik niet als een optie.[/edit]

..

Het grootste probleem wat wij hebben met het localizeren, is layout technische zaken. In een taal zijn zinnen soms een stuk langer dan in andere talen. Met PHP heb je daar waarschijnlijk minder last van.

[iamcj]

Ik heb er totaal geen verstand van, maar ik zou een database maken met de talen of je zou ook de vertaling kunnen doen bij de invoer en dus de pagina's in alle talen op de server zetten en met een landId de juiste pagina's opvragen.


Met een database zou ik het zo doen:

Per pagina de id's van de gebruikte woorden opslaan in een tabel.

Vervolgens met 1 query alle elementen ophalen die gelijk de juiste variabelenaam krijgen conform de pagina.

Een php bestaat dan uit:
$De . $tafel . $is . $rood . "."

of

$1 . $2 . $3 . $4 . "."

Bovenstaande is te generen is op basis van de ingevoerde tekst "De tafel is rood", aanemende dat de nederlanse database is gevuld.

Het is moeilijk om er wat zinnig over te zeggen wanneer ik niet de werking van je CMS weet

Maak een tabelletje (taal, code, tekst) en haal bij iedere request de gewenste tekst op. Doe dit wel in één keer (minder queries naar de database); je moet aan het begin van het script dus weten welke teksten je nodig hebt (of zet dit ook in een tabel...).
Genereer vervolgens de pagina en bewaar deze op schijf (hoef je niet iedere keer de pagina op te bouwen; alleen wanneer de data veranderd is).

Zoals je allicht weet is het mogelijk (bij een goede browser iig) een Accept-Language in te stellen. Deze kun je dus ook uitlezen.

Bijvoorbeeld:
GET /computers
Accept-Language: nl, en;q=0.8

--
nl heeft de voorkeur. Genereer de /computers pagina in het nederlands en bewaar deze bijv. als /cached/computers.nl

De volgende keer dat iemand /computers opvraagd (en als voorkeurstaal nl heeft ingesteld), controleer je of deze in /cached staat en de data (in de database oid) niet is veranderd. Zo ja, dan het ge-cachede bestand terug geven, anders generen (en opslaan).

[Manuzhai]

De beste manier is met behulp van gettext.

[Dr HenDre]

gettext kende ik niet, maar ziet er goed uit.

Wat ik altijd doe is het volgende:

de taal ophalen vanuit accept-language (als dat niet geset is kan de gebruiker zelf kiezen of is er een default-taal), zodra de taal bepaald is bestand openen (of includen) en alle inhoudt (is bij mij meestal vrij weinig) opslaan in een sessie, zo heb je alle text altijd bij de hand. Hiermee is nog steeds het probleem van de keuze tussen namen of nummers voor je probleem niet opgelost. Ik gebruik zelf altijd namen, omdat je van nummers totaal niet weet wat ze doen.
Dus als ik het volgende heb:

PHP-code:

$foo->handle_error($_SESSION['query_failed'], $_SERVER['PHP_SELF'], $_SERVER['REMOTE_ADDR']); 


en ik zie dit later bij onderhoud/aanpassingen of zels gewoon tijdens het scripten, dan weet ik meteen wat het doet, als er bv zou staan $_SESSION[5], dan zou ik echt niet weten wat het doet en moet ik erover nadenken.
Het gebruik van woorden ipv cijfers heeft wel als nadeel dat namen vaak inconsequnt zijn, maar ach

[Enlightenment]

Marcade schreef op 16-07-2005 @ 18:46 :
En hoe moet het dan met met cross-modulaire verwijzingen; neem aan dat je niet meerdere elementen wil reserveren voor hetzelfde woord.

Hoe bedoel je? Dat ik twee keer dezelfde zinnen definieer? Ik dacht aan 1 textfile, waar dan ook alle text voor modules in staat. Een andere mogelijkheid zou zijn om in de module de module-specifieke text te declareren, maar dat lijkt me alleen maar omslachtig.

Die functie moet de vertaling toch ook ergens vandaan halen; uit een array, of uit een file? Als ik moest kiezen tussen het continue lezen van een taalfile of een array; kies ik voor 't laatste. Een functie die een string teruggeeft moet snel werken sinds het vaak aangeroepen word.

Het zou ook uit database kunnen, of een andere backend, zoals gettext waar Manuz op doelde.

[edit] Daarbij wel dus dat de array gevuld word dmv. een taal specifieke file (bv. een .csv file; lekker makkelijk icm. Excel) . Taal hardcoderen in de code zelf zie ik niet als een optie.[/edit]

Daar wil ik dus vanaf, ik wil nu eigenlijk alle taal met taalmodules doen en niet meer hardcoded in de scripts. Zo kan de admin ook de taalmodule aanpassen en een custom taalmodule gebruiken, om bepaalde woorden/zinnen aan te passen. Flexibiliteit! Maarehhh Excel?!

Het grootste probleem wat wij hebben met het localizeren, is layout technische zaken.

Mja ik denk dat ik daar minder problemen mee heb.

In een taal zijn zinnen soms een stuk langer dan in andere talen. Met PHP heb je daar waarschijnlijk minder last van.

Hoezo? Het maakt voor de client toch niet uit of de HTML wordt uitgepoept door PHP of ASP?

[Enlightenment]

eddie schreef op 16-07-2005 @ 20:43 :
Het is moeilijk om er wat zinnig over te zeggen wanneer ik niet de werking van je CMS weet

Globaal: ik werk met mod_rewrite om *alle* requests te redirecten naar een master.php die vervolgens andere bestanden include op basis van de URL. Gaat het om een URL die begint met /images/ (of wat ingesteld is), dan zal de image handler worden aangeroepen. Als alle statische redirects zijn geweest, wordt in de database gekeken of er een node (pagina) vast zit aan de URL, zo niet een 404. Mijn CMS wijkt wellicht af van soortgelijke CMS'en, zoals b.v. geen files in de docroot (afgezien van opgeslagen images en files; die zet ik niet in de database ).

Zoals je allicht weet is het mogelijk (bij een goede browser iig) een Accept-Language in te stellen. Deze kun je dus ook uitlezen. (..) Genereer de /computers pagina in het nederlands en bewaar deze bijv. als /cached/computers.nl

Het kiezen van de taal heb ik eigenlijk al geregeld, welke deels ook afhangt van de Accept-Language. Ook cache-control etc. is geregeld, hij stuurt keurig 304's terug als de content niet is veranderd (ook voor images/files). Het gaat echt om de back-end van mijn taalmodules, wat er met de client gebeurt is al geregeld.

Manuzhai schreef op 17-07-2005 @ 08:24 :
De beste manier is met behulp van gettext.

Ziet er interessant uit, alleen jammer dat ik maar weinig info zie over de werking van gettext op php.net.

Dr HenDre schreef op 17-07-2005 @ 09:56 :
Ik gebruik zelf altijd namen, omdat je van nummers totaal niet weet wat ze doen.

Goed punt.

Enlightenment schreef op 16-07-2005 @ 18:31 :
Mijn CMS zit iets anders in elkaar.
Er staan b.v. helemaal geen bestanden in de documentroot.

Dat is bij mijn websites ook niet, maar je snapt wwel dat dat niet van belang is waar het staat.
Het ging erom dat ieder bestand een eigen file heeft...

Enlightenment schreef op 16-07-2005 @ 18:31 :

Wat betreft $lang['blub'], dan ga je toch weer namen verzinnen en dat moet je allemaal bijhouden, of dat makkelijker is dan nummers? Ik dacht zelf overigens aan $lang[<modulenaam>][1], dus per module/plugin/corefunctie/pagina heb je een array.

De namen verzin je over het algemeen zelf, het zal dan ook sneller terug te zoeken zijn dan getallen.
En als je het per array doet en alsnog samen in 1 file die die in moet laden, bij een kleine website isdat niet erg maar als de website enigzins uitgebreid wordt dan kan dit oplopen tot vele 100en kb's.

Enlightenment schreef op 16-07-2005 @ 18:31 :

De grote vraag is of een shitload aan vars dus niet voor een hoge overhead zorgt, ook al beperk je je tot 1 taal per file. Is het niet efficienter om een functie te gebruiken die somehow alleen de text teruggeeft die nodig is? Zit zelf nog wat te brainstormen hierover.

En dus aparte taalbetanden


Al ik he topic doorlees lijkt mijn methode nog steeds de meest effectieve.
Ik laat die van Manu even erbuiten omdat ik hier zelf ook nog niet serieus naar heb gekeken en dus niet kan beoordelen.

[Manuzhai]

De manier die ik heb aangegeven is DE geaccepteerde standaardmanier om het te doen. Lijkt me veel netter dan je eigen homegrown ding. Meer info (maar jullie hadden ook zelf even kunnen Googlen, php.net is natuurlijk niet de enige resource):

http://www.onlamp.com/pub/a/php/2002/06/13/php.html
http://ruistech.com/gettext/howto.php
http://www.uberdose.com/php/php-and-gettext-for-i18n/

[Marcade]

Enlightenment schreef op 17-07-2005 @ 15:53 :
Hoe bedoel je? Dat ik twee keer dezelfde zinnen definieer? Ik dacht aan 1 textfile, waar dan ook alle text voor modules in staat. Een andere mogelijkheid zou zijn om in de module de module-specifieke text te declareren, maar dat lijkt me alleen maar omslachtig.

Nee dat je juist niet 2 keer dezelfde zinnen definieert.

Daar wil ik dus vanaf, ik wil nu eigenlijk alle taal met taalmodules doen en niet meer hardcoded in de scripts. Zo kan de admin ook de taalmodule aanpassen en een custom taalmodule gebruiken, om bepaalde woorden/zinnen aan te passen. Flexibiliteit! Maarehhh Excel?!

Het gaat niet perse om excel maar om het CSV formaat; dat is een van de simpelste formaten die er is, waar makkelijk mee te werken valt. Onder andere met Excel.

Hoezo? Het maakt voor de client toch niet uit of de HTML wordt uitgepoept door PHP of ASP?

Ik doelde meer op applicaties; niet perse HTML of webbased dingen. Een van de grote problemen die wij hebben is dat we applicaties moeten vertalen waarbij de layout compleet verneukt word als de lengtes van strings enorm verschillen.

Het zou ook uit database kunnen, of een andere backend, zoals gettext waar Manuz op doelde.

Is een goede optie. gettext is duidelijk bedoelt voor NLS zaken.

[Marcade]

Oh, en het gebruiken van namen of nummers; ik ben een voorstander van nummers. Namen voor een tiental woorden wil nog wel werken; maar voor honderden (duizenden) dan wil je dat echt niet doen. In het begin is het nog makkelijk namen te verzinnen, maar later zal 't een zooitje worden. Je onthoud het sowieso niet en moet het alsnog/sowieso bijhouden in een lijst. Het voordeel van nummers is dat je groepen kan maken die je makkelijk kan uitbreiden. Of nog makkelijker, een combinatie .. nummers met prefixes en/of suffixes.

[Manuzhai]

Wat ze volgens mij in Subversion doen (ik meen dat dat ook iets gettext-achtigs gebruikt, maar weet het niet zeker) is de Engelse variant als key gebruiken voor alle andere varianten. Dat is op zich best handig; je hoeft geen nieuwe naam te bedenken, maar gebruikt gewoon de tekst zelf in een bepaalde taal.

[Marcade]

Manuzhai schreef op 17-07-2005 @ 19:48 :
Wat ze volgens mij in Subversion doen (ik meen dat dat ook iets gettext-achtigs gebruikt, maar weet het niet zeker) is de Engelse variant als key gebruiken voor alle andere varianten. Dat is op zich best handig; je hoeft geen nieuwe naam te bedenken, maar gebruikt gewoon de tekst zelf in een bepaalde taal.

Voor (een groep) zinnen / lappen tekst lijkt me dat nogal onpraktisch?

[Manuzhai]

Marcade schreef op 17-07-2005 @ 20:29 :
Voor (een groep) zinnen / lappen tekst lijkt me dat nogal onpraktisch?

Wellicht; ik weet niet precies hoe het in Subversion werkte. Je zou het natuurlijk ook met de MD5 van de Engelse tekst kunnen doen.

Enlightenment schreef op 17-07-2005 @ 16:02 :
Het gaat echt om de back-end van mijn taalmodules, wat er met de client gebeurt is al geregeld.

?

Kun je je vraag dan iets verduidelijken?