[PHP]Meertalig / Multilanguage

[BlackHawkDesign]

Hey medetweakers,

Er zijn al meerdere topics over dit onderwerp geschreven,echter is het antwoord in deze topics voor mij nog niet helemaal voldoende.

Situatie
Ik ben bezig met het ontwerpen van een community wat ik helaas niet nader kan beschrijven. Echter wil ik rekening mee houden dat deze in de toekomst meertalig moet zijn. Ook wil ik er rekening mee houden dat deze door veel gebruikers bezocht zal worden. Ik vind dus belangrijk dat de vertaling dus goed onderhoudbaar is en snel is. Het gaat niet om complete teksten, maar meer om woorden zinnen zoals, login, uw sessie is verlopen e.d

Methoden
Ik heb meerdere methoden al gezien en eigenlijk komen ze allemaal neer op de volgende :
- Database: Naar mijn mening is dit niet bepaald snel en bij veel bezoekers ben ik bang dat het aantal queries enorm oplopen
- Een los bestand met daarin een array of define statements: Op zich loopt dat al een stuk beter, maar wanneer ik later woorden/zinnen toevoeg moet ik in alle taalbestanden deze woorden toevoegen.. Ook vraag ik me af hoe snel dit is
- Gettext van php zelf: Het lijkt een hele mooie oplossing en misschien wel de beste, maar sommige mensen beweren dat het een zootje rommel is. Wat is jullie mening hierover?

Ik hoor graag jullie mening.. en als jullie nog iets veel beters weten: GRAAG!

[Spinal]

BlackHawkDesign schreef op woensdag 25 februari 2009 @ 12:25:

Methoden
Ik heb meerdere methoden al gezien en eigenlijk komen ze allemaal neer op de volgende :
- Database: Naar mijn mening is dit niet bepaald snel en bij veel bezoekers ben ik bang dat het aantal queries enorm oplopen
- Een los bestand met daarin een array of define statements: Op zich loopt dat al een stuk beter, maar wanneer ik later woorden/zinnen toevoeg moet ik in alle taalbestanden deze woorden toevoegen.. Ook vraag ik me af hoe snel dit is
- Gettext van php zelf: Het lijkt een hele mooie oplossing en misschien wel de beste, maar sommige mensen beweren dat het een zootje rommel is. Wat is jullie mening hierover?

Ik hoor graag jullie mening.. en als jullie nog iets veel beters weten: GRAAG!

Ik heb zelf ooit geprobeerd te werken met gettext, maar is me totaal niet goed bevallen. Het schijnt ook heel vreemd te werken als er meerdere mensen tegelijk ingelogd zijn met verschillende talen (zoeken hier op GoT levert vast wel wat resultaten daarover op)
Ik werk daarom met jouw tweede methode: verschillende bestanden voor de talen, met 1 bestand waarin alle tekst staat die nog niet vertaald is in alle talen. Misschien lichtelijk omslachtig, maar het werkt prima voor mij.

[Cartman!]

Neem eens een kijkje bij Zend Framework, daar zit een module Zend_Translate in en ondersteunt enorm veel manieren van bronbestanden. Er zit ook n threadsafe implementatie van gettext in. http://framework.zend.com/manual/en/zend.translate.html

[nika]

Heb je gedacht aan comma seperated variables (csv files)? Werk ik zelf mee en werkt prima. Voor iedere taal een aparte csv. Mooie is dat derder heel eenvoudig kunnen wijzigen en toevoegen (bv. in Excel).

[Face_-_LeSS]

Of een combinatie van database en textfiles. Het muteren van de labels kan je dan in de database doen, lekker makkelijk. Vervolgens genereer je na een verandering in de database het textbestand (bijv. csv) opnieuw, die je gebruikt om de vertaling te laden in je applicatie.

Voordelen:
- Eenvoudig muteren (beheren)
- Snel inlezen
- Weinig queries

Je kan ook bij iedere mutatie een php-file genereren vanuit de database. Zoiets:

labels-nl.php

PHP:

$label = array
(
  'Welcome' => 'Welkom',
  'Your session has expired' => 'Uw sessie is verlopen',
  'Todays date' => 'Het is vandaag %s',
  'etc' => 'enz',
);

[ Voor 34% gewijzigd door Face_-_LeSS op 25-02-2009 13:43 ]

[BlackHawkDesign]

@Zanderz: Ja dat kwam ik al meerdere malen tegen op andere sites. Ik vroeg me dus af of het echt niet helemaal lekker werkt of het gewoon het onkunnen van die mensen was. Maar gettext zal dan wel niet zon lekker verhaal worden. Oke geen gettext meer dus.

@Cartman: Op zich inderdaad een mooie tussenoplossing. Maar volgens mij werkt dat net zo snel als een eigen gemaakt php scriptje zoals met een taalbestandje. Ik dacht namelijk aangezien dat gettext anders werkt dat het dus ook een stuk sneller zou zijn. Ik ben niet te beroerd om zelf wat te schrijven, ik wil gewoon de beste oplossing

@Nika: Dus toch ook die 2e methode. Dat van die cvs file is inderdaad een goeie extra toevoeging. Dan kunnen mensen het inderdaad mooi bewerken in hun vertrouwde excel omgeving. Alleen zijn er wel steeds 2 php bewerkingen nodig om het in een php array te krijgen bij elke page request.

Ik denk dat ik genoeg weet: eigen gemaakte manier: losse bestanden voor elke taal 1 en dan even nadenken of het bewerken voor non programmeurs een pre is.

Bedankt mensen, ik ben weer wat meer info rijker!

EDIT: @ Faceless, je was aan het reageren toen ik me verhaaltje aan het tikken was. Inderdaad dat is ook een mooie oplossing. Dan heb je eenmaal dat omzetten(als ik als output een php file maak met een array erin) en toch een goeie bewerkomgeving. Die is helemaal nice.

Ik ga er een vet systeempje van maken. Eerst nog even de rest van de requirements op papier knallen, ik laat nog weten wat het geworden is

[ Voor 15% gewijzigd door BlackHawkDesign op 25-02-2009 13:40 ]

[Hydra]

nika schreef op woensdag 25 februari 2009 @ 13:06:
Heb je gedacht aan comma seperated variables (csv files)? Werk ik zelf mee en werkt prima. Voor iedere taal een aparte csv. Mooie is dat derder heel eenvoudig kunnen wijzigen en toevoegen (bv. in Excel).

Ja, want dit is natuurlijk veel performanter dan een database

[HuHu]

Hydra schreef op woensdag 25 februari 2009 @ 13:41:
[...]


Ja, want dit is natuurlijk veel performanter dan een database

Dat is veel wat?

Maar een CSV bestand inlezen en exploden op de ; kan best beter zijn dan een database. Scheelt de overhead van het maken van connecties naar de database.

[BlackHawkDesign]

@Hydra: Nou je verdeelt wat meer de resources. Als je alleen al 30 queries krijgt bij elke page request om alleen al de juiste teksten weer te geven, krijg je bij een leuk bezoekersaantal toch echt wel problemen met je database.

Het nadeel van een csv bestand tegenover een php array is dat het 2x de explode functie nodig heeft. Dat kost bij elke page request ook weer onnodige energie.

Dan is toch die oplossing van faceless erg mooi bedacht

Nu nog even nadenken of ik zon vette interface wil gaan bouwen of gewoon zelf de losse php bestandjes aanmaak.

[4VAlien]

waarom niet alle teksten met 1 query uit de database halen en in array gooien bij het begin van de pagina? Je zegt zelf dat het maar om kleine hoeveelheden tekst gaat. Dan kan de bewerking door derden ook op meer manieren vorm worden gegeven.

[Cartman!]

4VAlien, dat is wat ik doe met een eigen adapter voor Zend_Translate, komt in feite neer op de Array adapter en het werkt erg goed. Het handige aan Zend_Translate is dat je die basisdingen niet meer hoeft te maken. Je kunt het aanroepen met iets als:

PHP:

echo $translate->_('Welkom');

En vind ie een vertaling voor deze entry in de gewenste taal dan returned ie dat, anders laat ie t origineel staan. Wel zo makkelijk In een DB is het voordeel dat je in n CMS zelf makkelijk de content kunt bewerken (of je klant).

[Verwijderd]

Face_-_LeSS schreef op woensdag 25 februari 2009 @ 13:28:
Of een combinatie van database en textfiles. Het muteren van de labels kan je dan in de database doen, lekker makkelijk. Vervolgens genereer je na een verandering in de database het textbestand (bijv. csv) opnieuw, die je gebruikt om de vertaling te laden in je applicatie.

Voordelen:
- Eenvoudig muteren (beheren)
- Snel inlezen
- Weinig queries

Je kan ook bij iedere mutatie een php-file genereren vanuit de database. Zoiets:

labels-nl.php

PHP:

$label = array
(
  'Welcome' => 'Welkom',
  'Your session has expired' => 'Uw sessie is verlopen',
  'Todays date' => 'Het is vandaag %s',
  'etc' => 'enz',
);

mee eens. Gebruik dit ook bij één van mijn webwinkels en deze is in ruim 6 talen beschikbaar en het is naar mijn idee de makkelijkste/snelste en meest onderhoudvriendelijkste manier

[ZpAz]

Ikzelf had eerst altijd een map languages met daarin php bestanden met een array van de informatie, dus een dutch.php, english.php e.d en dan zo:

code:

$lang['firstName'] = 'voornaam';
$lang['lastName'] = 'achternaam';

Op zich is het prima aan te passen, maar ik heb voor komende projecten uitgewerkt als xml bestanden welke uit worden gelezen en aan de hand daarvan de vertaalslag wordt gedaan, wel weer heeft elke taal een eigen bestand (dutch.xml, english.xml e.d)

en dan ziet het er zo uit:

code:

<language>
<firstName>voornaam</firstName>
<lastName>achternaam</lastName>
</language>

[4VAlien]

@Zpaz: wat is het voordeel? Of zie ik een voordeel op de lange termijn over het hoofd?

[ZpAz]

4VAlien schreef op woensdag 25 februari 2009 @ 14:37:
@Zpaz: wat is het voordeel? Of zie ik een voordeel op de lange termijn over het hoofd?

Netheid, althans dat vind ik dan. Ook is het leesbaarder voor bijvoorbeeld eventueel een vertaler.

[Hydra]

Ik vind alle hier genoemde oplossingen welke niet database-gebaseerd zijn gewoon smerig. Kennelijk is database performance een issue, maar een CSV bestand splitten of voor iedere request een heel .php bestand includen niet. Afgezien van het performance verhaal (performant is gewoon een anglicisme wat veel in de IT gebruikt wordt), is het ook nog eens erg simpel een admin-script te maken wat een gebruiker toe staat extra talen toe te voegen. Bizar dat toch voor text-files gekozen wordt.

[Icekiller2k6]

Hydra schreef op woensdag 25 februari 2009 @ 15:10:
Ik vind alle hier genoemde oplossingen welke niet database-gebaseerd zijn gewoon smerig. Kennelijk is database performance een issue, maar een CSV bestand splitten of voor iedere request een heel .php bestand includen niet. Afgezien van het performance verhaal (performant is gewoon een anglicisme wat veel in de IT gebruikt wordt), is het ook nog eens erg simpel een admin-script te maken wat een gebruiker toe staat extra talen toe te voegen. Bizar dat toch voor text-files gekozen wordt.

Hydra.. wat je doet is je slaat alles op @DB
maar moment dat je iets 'AANPAST' in db maak je een PHP file of een CSV of XML,.. aan.

Op die manier is alles toch in een 'mooi' db maar omdat hij een PHP page genereert met de data is het 'mooier'...

[Verwijderd]

Hydra schreef op woensdag 25 februari 2009 @ 15:10:
Ik vind alle hier genoemde oplossingen welke niet database-gebaseerd zijn gewoon smerig. Kennelijk is database performance een issue, maar een CSV bestand splitten of voor iedere request een heel .php bestand includen niet. Afgezien van het performance verhaal (performant is gewoon een anglicisme wat veel in de IT gebruikt wordt), is het ook nog eens erg simpel een admin-script te maken wat een gebruiker toe staat extra talen toe te voegen. Bizar dat toch voor text-files gekozen wordt.

Uit een van mijn test kwam naar voren dat het sneller was om een text file te includen( deze word aangemaakt van uit een DB) dan eerst alle regels uit de database te halen per request....
verschil was iets van 15%... best duidelijk verschil dan toch?

[HuHu]

Hydra schreef op woensdag 25 februari 2009 @ 15:10:
Ik vind alle hier genoemde oplossingen welke niet database-gebaseerd zijn gewoon smerig. Kennelijk is database performance een issue, maar een CSV bestand splitten of voor iedere request een heel .php bestand includen niet. Afgezien van het performance verhaal (performant is gewoon een anglicisme wat veel in de IT gebruikt wordt), is het ook nog eens erg simpel een admin-script te maken wat een gebruiker toe staat extra talen toe te voegen. Bizar dat toch voor text-files gekozen wordt.

Performant is een mij onbekend anglicisme en ook nog eens vrij smerig.

Verder zijn tekst-bestanden helemaal niet zo'n gekke keuze, mits je ze klein en overzichtelijk houdt. Heb je een site met vele teksten en vele talen, dan worden tekst-bestanden gewoon onhandelbaar.

Overigens is een tekst-bestand qua principe niet veel anders dan een database: je hebt een locatie waar je key-value paren kunt opslaan en opvragen. Of je daar nu een tekst-bestand voor gebruikt of een database voor uitleest, het principe blijft hetzelfde.

Iets als Zend_Translate biedt trouwens standaard 9 (!) bestandsgebaseerde oplossingen aan en geen enkele database-oplossing. Daaruit kun je toch wel voorzichtig concluderen dat een bestandsgebaseerde oplossing nog helemaal zo'n gek idee niet is.

Alleen de optie "array" wordt afgeraden indien de vertaling door anderen dan de programmeur (of het team) zelf geschiedt, maar voor een wat kleiner project is het een prima keuze.

[HuHu]

Verwijderd schreef op woensdag 25 februari 2009 @ 15:19:
[...]


Uit een van mijn test kwam naar voren dat het sneller was om een text file te includen( deze word aangemaakt van uit een DB) dan eerst alle regels uit de database te halen per request....
verschil was iets van 15%... best duidelijk verschil dan toch?

Over het algemeen is een verschil van 15% op slechts het inlezen van een tekst natuurlijk een peulenschil in vergelijking met wat er allemaal moet gebeuren om een volledige pagina op je scherm te tonen. Dat soort tests worden pas relevant op het moment dat je site de grootte van FOK! of Tweakers begint te naderen.

Het gaat er om dat je als programmeur iets maakt wat duidelijk en doeltreffend is en wat voor jezelf ook nog eenvoudig en begrijpbaar is. Iets simpels als een bestand met een array voldoet aan al die eisen, dus dat kun je dan prima zelf maken (of middels Zend_Translate).

[Face_-_LeSS]

Er is niks mis met tekstbestanden vind ik, zolang je maar niet zelf dingen gaat aanpassen in die bestanden. Gewoon genereren vanuit de management-laag, en als de vertalers met xml, csv of wat dan ook werken kan je gewoon zorgen dat je vanuit de applicatie deze bestanden kan importeren.

Volgens mij gebruikt Microsoft Dynamics (volledig DB georiënteerd ERP systeem) ook textbestanden voor de vertalingen i.v.m. performance.

[.oisyn]

Ik zie dat het nog door niemand genoemd is, maar de correcte termen zijn internationalization (afgekort i18n) en localization (l10n). Het eerste (i18n) gaat vooral om de omzetting van een locale-specifiek systeem naar iets generieks wat meerdere locales (en dus talen) ondersteunt (en waarin jij momenteel in geïnteresseerd bent). L10n is vervolgens het proces van het implementeren van specifieke locales.

Hiermee heb je wellicht wat betere zoektermen

[ Voor 4% gewijzigd door .oisyn op 25-02-2009 15:57 ]

[Hydra]

Face_-_LeSS schreef op woensdag 25 februari 2009 @ 15:35:
Er is niks mis met tekstbestanden vind ik, zolang je maar niet zelf dingen gaat aanpassen in die bestanden. Gewoon genereren vanuit de management-laag, en als de vertalers met xml, csv of wat dan ook werken kan je gewoon zorgen dat je vanuit de applicatie deze bestanden kan importeren.

Als die bestanden groot worden moet je in PHP voor elke request de hele file parsen, terwijl je misschien maar 1 entry nodig hebt.

Volgens mij gebruikt Microsoft Dynamics (volledig DB georiënteerd ERP systeem) ook textbestanden voor de vertalingen i.v.m. performance.

Kun je niet vergelijken aangezien die informatie in de applicatie gecached wordt.

[jvbijleveld]

Zodra het aantal labels binnen de perken blijft is een statische array in een include best een prima oplossing. Echter, zodra deze begint te groeien (an ik kan me voorstellen dat je dat met vertalingen al snel gaat krijgen) is een database de beste oplossing. Zeker wanneer er labels bij komen die je niet op elke pagina nodig hebt kan je met een database selecties maken van de records die je echt nodig hebt.

Een externe file, csv of xml kan mijns inziens nooit een degelijke oplossing zijn, het inlezen van een externe file kost netto net zo veel tijd/moeite/performance als een Query, maar is een stuk minder flexibel.

[Bram77]

XML gebruiken is uiteindelijk netter, universeler en makkelijker in gebruik dan een array. Bij het gebruik van een database moet je ook weer een interface schrijven om het te beheren. Wel het aller mooist natuurlijk. Om de snelheid te garanderen kun je gewoon een XML bestand genereren uit je database. Je hergenereerd het bestand gewoon elke keer opnieuw bij het starten van een sessie, per user. Kost een beetje tijd bij het initiele laden, maar dat lijkt het me waard. Maar goed, dan moet je dus wel een interface willen bouwen om de taal-gedeelte te beheren.

De belangrijkste reden om XML te gebruiken zijn dat het een duidelijk standaard is en dat er een hoop functionaliteit in php geintegreerd zit om er mee te werken.

Ik heb het zelf met een array en met XML (zonder DB) gedaan. XML is iets meer werk, maar uiteindelijk wel veel makkelijker te beheren. Betaald zichzelf terug. Een array is de luie manier

[ Voor 32% gewijzigd door Bram77 op 25-02-2009 16:10 ]

[roeleboel]

Je hergenereerd het bestand gewoon elke keer opnieuw bij het starten van een sessie, per user.

Wat is daar het nut van? Gewoon 1 keer (her-)genereren per wijziging in de betreffende taal is toch meer dan genoeg? Waarom zou je dit per opgestarte sessie doen? Dat biedt toch geen meerwaarde?

[jvbijleveld]

Bram77 schreef op woensdag 25 februari 2009 @ 16:08:
Kost een beetje tijd bij het initiele laden, maar dat lijkt het me waard.

Juist bij het initiele laden wil je geen overhead. In plaats van alles in een keer in het begin in te lezen kan je er dus ook gewoon voor kiezen om per pagina te kijken wat je echt nodig hebt, en daar op te querieen.
Als je echt overhead wilt besparen gebruikje dat dan icm een template systeem (smarty bijv) en zet je template caching aan.

...en wat is er mis met phpMyAdmin als beheer module voor de vertalingen? Zolang de designer de enige is die vertalingen toe hoeft te voegen werkt dat prima. Zodra derden zich ermee gaan bemoeien hang je sowiezo aan een beheermodule, als is het alleen maar voor input validation.

[Face_-_LeSS]

Hydra schreef op woensdag 25 februari 2009 @ 15:53:
[...]


Als die bestanden groot worden moet je in PHP voor elke request de hele file parsen, terwijl je misschien maar 1 entry nodig hebt.

Als alle labels in één groot bestand gezet worden wel. Maar als je een database gebruikt zal je ook per request alle vertalingen van de geselecteerde taal op moeten halen want als je 400 labels voor een pagina nodig hebt ga je niet 400 queries uitvoeren.

En als je weet wanneer je welke labels nodig hebt, kan je natuurlijk gewoon verschillende kleinere tekstbestanden gebruiken.

[ Voor 11% gewijzigd door Face_-_LeSS op 25-02-2009 16:29 ]

[HuHu]

Hydra schreef op woensdag 25 februari 2009 @ 15:53:

[...]

Kun je niet vergelijken aangezien die informatie in de applicatie gecached wordt.

Wat let je om in je eigen applicatie ook caching te implementeren? Als je een beetje grote site maakt ga je toch al cachen, dus dan kun je vertaalbestanden meteen meesturen naar de cache.

[Hydra]

HuHu schreef op woensdag 25 februari 2009 @ 16:28:
Wat let je om in je eigen applicatie ook caching te implementeren?

Niet, dat is voor drukke sites sowieso min of meer een must.

Als je een beetje grote site maakt ga je toch al cachen, dus dan kun je vertaalbestanden meteen meesturen naar de cache.

IMHO vul je die cache dan aan de hand van de DB, die bestanden uitgenereren naar file heeft dan 0 nut.

Face_-_LeSS schreef op woensdag 25 februari 2009 @ 16:22:
En als je weet wanneer je welke labels nodig hebt, kan je natuurlijk gewoon verschillende kleinere tekstbestanden gebruiken.

Hoe verdeel je de labels dan? Per 'pagina' een 'include' bestand?

Bram77 schreef op woensdag 25 februari 2009 @ 16:08:
XML gebruiken is uiteindelijk netter, universeler en makkelijker in gebruik dan een array. Bij het gebruik van een database moet je ook weer een interface schrijven om het te beheren.

Maar gebruikers laat je met notepad XML bestanden aanmaken?

Wel het aller mooist natuurlijk. Om de snelheid te garanderen kun je gewoon een XML bestand genereren uit je database. Je hergenereerd het bestand gewoon elke keer opnieuw bij het starten van een sessie, per user. Kost een beetje tijd bij het initiele laden, maar dat lijkt het me waard. Maar goed, dan moet je dus wel een interface willen bouwen om de taal-gedeelte te beheren.

Wat heeft het 'garanderen' van snelheid te maken met het uitgenereren van XML? En wat is het nut van het per sessie hergenereren of bewaren van deze informatie? Dit is gewoon info die globaal is en nauwelijks wijzigd. Het heeft 0 nut dit per sessie te genereren. Voor kleine sites kun je het prima rechtstreeks uit de DB trekken. Voor grote sites cache je het globaal in de applicatie.

De belangrijkste reden om XML te gebruiken zijn dat het een duidelijk standaard is en dat er een hoop functionaliteit in php geintegreerd zit om er mee te werken.

Er zit een hoop functionaliteit in PHP om met databases te werken.

[ Voor 71% gewijzigd door Hydra op 25-02-2009 16:42 ]

[Cartman!]

Bram77: ik snap niet waarom je perse XML netter vind dan een array. Met een simpel script kun je een array omzetten naar XML en andersom ook. Dus als een vertaler liever werkt met XML kun je em zo converten voor em en later weer terug naar array. Ik denk dat PHP sneller met arrays werkt dan met XML files (denk ik, niet getest).

De reden dat Zend_Translate geen Database adapter heeft is vrij logisch, je weet nooit wat voor Db iemand gebruikt, wat voor model ie heeft etc. De manual zegt daarom ook dat je makkelijk zelf een db-gebaseerde manier kunt maken door te Zend_Translate_Adapter te extenden. Ik vind dat makkelijk onderhouden voor mezelf en later ook voor klanten in n CMS waar ze nieuwe vertalingen zelf kunnen toevoegen bijvoorbeeld. De site heeft 1 query voor t ophalen van de vertaling en een x aantal minuten daarna krijgen andere de cache versie te zien. Performance is wat dat betreft niet echt n issue dus, ik denk zelfs dat t veel sneller is dan exotische files die PHP eerst helemaal moet gaan parsen ipv. die simpele query die n array.

[JayVee]

BlackHawkDesign schreef op woensdag 25 februari 2009 @ 12:25:
- Gettext van php zelf: Het lijkt een hele mooie oplossing en misschien wel de beste, maar sommige mensen beweren dat het een zootje rommel is. Wat is jullie mening hierover?

Wij gebruiken voor onze applicatie nu al een jaar gettext, en dat draait zover wij zien als een zonnetje. Het probleem dat soms de verkeerde taal gebruikt wordt heb je alleen bij niet-thread safe versies van Apache (dacht ik), dus zoek even goed uit voordat je deze optie wellicht onterecht wegstreept.

Hier even wat links die mij hebben geholpen een beslissing te nemen:
• http://mel.melaxis.com/de...-web-sites-using-gettext/
• http://mel.melaxis.com/de...n-is-gettext-fast-enough/
• http://www.litfuel.net/plush/?postid=84

De andere redenen waren:
• verzin niet zelf iets als het al bestaat
• bestaande tooling (voor beheer message files)

[ Voor 6% gewijzigd door JayVee op 25-02-2009 17:22 ]

[link0007]

ik persoonlijk gebruik associatieve arrays.. Zo hoef je geen kracht te verspillen aan het omzetten van je data naar een array/resultset, en kan je nog steeds eenvoudig vertalen. Je hebt alleen wel een probleem dat de vertalingen geen syntaxfouten mogen veroorzaken, maar dat is redelijk eenvoudig te controlleren voor implementatie van de vertaling.

Er is wel altijd nog een kwestie van juiste afhandeling van missende vertaalzinnen. In mijn implementatie hou ik een "standaard vertaling" (de engelse vertaling) bij, en dan laad ik daarnaast de gewenste vertaling in. Zo kan ik controleren of de zin bestaat in de gewenste vertaling, zo niet gebruik ik de zin uit de standaard vertaling. als beide niet bestaan, gebruik ik de key.

[ Voor 35% gewijzigd door link0007 op 26-02-2009 01:34 ]

[mithras]

JayVee schreef op woensdag 25 februari 2009 @ 17:19:
[...]

De andere redenen waren:
• verzin niet zelf iets als het al bestaat
• bestaande tooling (voor beheer message files)

QFT

Gettext is gewoon een bewezen methode. Het gebruik van gettext zie je niet alleen in webdevelopment, maar ook in desktop-applicaties terug. Ik snap ook niet dat iedereen zo ontzettend moeilijk doet met db of zelf gekluste file-based systemen.
Gettext is een file-based systeem, maar wel gecompileerd en vervolgens gecached. Dit versnelt het proces heel erg (check de bechmarks)! Daarnaast heeft gettext zoveel tools om te bewerken dat iedere vertaler vrijheid heeft in de manier waarop hij zijn vertaalbestand bewerkt.

Als je, tot slot, tegen de non-threadsafe problemen van gettext in php aanloopt, kan je kijken naar Zend_Translate, de Zend implementatie van gettext die wél threadsafe is

[Cartman!]

Dat is heel mooi maar hebben jullie nooit klanten die zelf teksten willen kunnen toevoegen/wijzigen/verwijderen vanuit een CMS? Zover ik weet kun je met gettext alleen lezen uit die files en niet ernaartoe schrijven. Hoe los jij dat op?

[mithras]

Cartman! schreef op donderdag 26 februari 2009 @ 09:21:
Dat is heel mooi maar hebben jullie nooit klanten die zelf teksten willen kunnen toevoegen/wijzigen/verwijderen vanuit een CMS? Zover ik weet kun je met gettext alleen lezen uit die files en niet ernaartoe schrijven. Hoe los jij dat op?

Je zal gettext ook alleen moeten gebruiken voor de standaard teksten in je cms, onafhankelijk van de content van het cms. Dingen als 'Reageer' bij een nieuwsbericht en 'Verstuur' bij een formulier dienen via gettext vertaald te worden.

De content zelf (pagina's etc) zullen door de gebruiker worden vertaald. Die staan, net al alle andere content van het cms, in de database. Ik ben ook van mening dat je het content gedeelte moet beperken tot datgene wat echt door een gebruiker te zien is als content. Alle standaardteksten op de website zouden niet door een gebruiker veranderd mogen worden.

[Spider.007]

mithras schreef op donderdag 26 februari 2009 @ 09:17:
[...]
QFT

Gettext is gewoon een bewezen methode. Het gebruik van gettext zie je niet alleen in webdevelopment, maar ook in desktop-applicaties terug. Ik snap ook niet dat iedereen zo ontzettend moeilijk doet met db of zelf gekluste file-based systemen.
Gettext is een file-based systeem, maar wel gecompileerd en vervolgens gecached. Dit versnelt het proces heel erg (check de bechmarks)! Daarnaast heeft gettext zoveel tools om te bewerken dat iedere vertaler vrijheid heeft in de manier waarop hij zijn vertaalbestand bewerkt.

Als je, tot slot, tegen de non-threadsafe problemen van gettext in php aanloopt, kan je kijken naar Zend_Translate, de Zend implementatie van gettext die wél threadsafe is

Gettext als implementatie is alleen bewezen in applicaties; juist niet voor het web. Als je een grotere applicatie in meerdere talen op Apache gaat draaien ga je gegarandeerd problemen met de niet-thread-safety van gettext / setlocale. Gettext als opslagformaat is geen slecht idee; maar de standaard gettext implementatie in PHP gebruiken is vragen om problemen.

[mithras]

Spider.007 schreef op donderdag 26 februari 2009 @ 09:40:
[...]
Gettext als implementatie is alleen bewezen in applicaties; juist niet voor het web. Als je een grotere applicatie in meerdere talen op Apache gaat draaien ga je gegarandeerd problemen met de niet-thread-safety van gettext / setlocale. Gettext als opslagformaat is geen slecht idee; maar de standaard gettext implementatie in PHP gebruiken is vragen om problemen.

Daarom, mocht je juist een groot webproject hebben waarin i18n belangrijk is, gebruik dan Zend_Translate. Deze heeft wel het gemak van gettext wat ook nog eens thread-safe is

[BlackHawkDesign]

Zucht jullie maken het er niet makkelijker op

Jayvee gaf wat mooie artikeltjes en volgens dit verhaal : http://mel.melaxis.com/de...n-is-gettext-fast-enough/ kan ik toch lichtelijk de conclusie trekken dat een implementatie van de get text methode eigenlijk nog trager is dan het gebruik van een simpele array?

Ik ga mijn conclusie trekken, aangezien ik nu van alle kanten wel een beetje te horen heb gekregen wat zij er van denken. Het was dus niet zo gek dat ik er niet uit kwam, want ook hier zijn de meningen erg verdeelt.

Bij mijn applicatie moet ik rekening mee houden dat hij meertaling wordt, Ik moet het dus erin bouwen, maar de kans dat het uberhaupt voor meer dan 3 a 4 talen wordt gebruikt is niet zo groot. Ik ben van plan het zo op te gaan zetten: Er komt een tabel in de database languages, deze bevat een kolom waarin de key staat, daarnaast is er voor elke taal een kolom. Ook bevat de tabel een kolom met categorie. Er komt daarnaast een scriptje dat handmatig aangeroepen gaat worden dat alleen bij elke wijziging een aantal php bestanden genereert afhankelijk van de categorien. Zoals het idee van Face_less, maar dan als toevoeging het gebruik van subgedeeltes, indien het bestand zelf te groot wordt.

Zo kan makkelijk via de db zelf of via een interface een taal worden toegevoegd. Dit systeem kan ik eenmalig bouwen en daarna hergebruiken.

Tweakers, ik wil jullie allemaal bedanken, elk van jullie heeft mij toch weer een stukje meer inzicht gegeven. Ik had nooit zoveel reacties verwacht en ik ben dan ook blij dat iedereen zijn steentje heeft bijgedragen.

Bedankt!

[ Voor 64% gewijzigd door BlackHawkDesign op 26-02-2009 10:11 ]

[Cartman!]

mithras schreef op donderdag 26 februari 2009 @ 09:24:
[...]
De content zelf (pagina's etc) zullen door de gebruiker worden vertaald. Die staan, net al alle andere content van het cms, in de database. Ik ben ook van mening dat je het content gedeelte moet beperken tot datgene wat echt door een gebruiker te zien is als content. Alle standaardteksten op de website zouden niet door een gebruiker veranderd mogen worden.

In een ideale wereld waar klanten aannemen dat je als bureau het beste weet wat goed voor ze is maar in de praktijk betalen ze juist extra voor zulke dingen. Tevens kun je vrij makkelijk een taalmodule inbakken in je CMS zodat ze later zelf een nieuwe taal kunnen toevoegen en de huidige content vertalen. Dat is voor mij een reden om (nog) geen gettext te gebruiken hoewel ik zeker de voordelen zie. Ik denk alleen toch dat het uitvoeren van 1 query sneller is dan t parsen van een gettext file