[PHP] Gettext en caching

[robbert]

Hoi,

ik ben bezig met een applicatie meertalig te ontwikkelen, hiervoor gebruik ik gettext. Dit lijkt allemaal erg leuk te werken, echter worden alle vertalingen gecached. Dit geeft erg rare gevolgen, als ik een aanpassing maak ik mijn taalbestanden krijg ik random de aangepaste string en de niet aangepaste string terug.

De oplossing zou een restart zijn van de webserver. Nu ben ik geen root op de webserver waar ik ontwikkel, dus die optie zit er niet in. Ook al zou ik rootrechten hebben lijkt het me ook niet handig om bij elke wijziging de webserver te herstarten.

Ook met wat zoeken vond ik weinig oplossingen. De enige oplossing die ik heb gevonden is de volgende:
• Geef je taalbestanden de datum van genereren in de naam
• Laadt het laatst genereerde taalbestand

Echter is dit nogal lelijk, weet iemand toevallig een nette oplossing voor dit probleem.

[ Voor 6% gewijzigd door robbert op 15-09-2007 20:14 ]

[LauPro]

Helaas, de gettext support zuigt in PHP. En dan druk ik me heel zacht uit. Je kan beter een eigen implementatie maken of een bestaande gebruiken.

[Verwijderd]

Geen gettext gebruiken? Zoals je misschien ergens kunt lezen is gettext niet thread safe. Ik wist overigens niet dat gettext ingelezen bestanden cachet. De combinatie is in dat geval erg onhandig. Is het overigens zo dat je wel elke keer handmatig de .mo bestanden maakt? Of pas je alleen de .po bestanden aan, en geloof je het verder wel?

De beste oplossing is echt om geen gettext te gebruiken. Het is vrij eenvoudig om zelf iets soortgelijks te schrijven, dit zou ik ook ten zeerste aanraden.

[Verwijderd]

LauPro schreef op zaterdag 15 september 2007 @ 20:22:
Helaas, de gettext support zuigt in PHP.

Volgens mij valt dat wel mee. Het is meer dat gettext in een multithreaded omgeving enorm zuigt. De gettext support in PHP CLI scripts zal best in orde zijn.

[LauPro]

Inherent aan PHP is toch wel min of meer dat deze draait in een MT-omgeving. Niemand gebruikt PHP CLI voor het serveren van web-requests. Ok, misschien is de implementatie in PHP goed, maar de non thread safety van gettext (en die van de onderliggende libs) is absoluut onacceptabel.

[Verwijderd]

LauPro schreef op zaterdag 15 september 2007 @ 20:34:
Inherent aan PHP is toch wel min of meer dat deze draait in een MT-omgeving. Niemand gebruikt PHP CLI voor het serveren van web-requests. Ok, misschien is de implementatie in PHP goed, maar de non thread safety van gettext (en die van de onderliggende libs) is absoluut onacceptabel.

Ok, PHP wordt meestal gebruik voor webscripting, maar laten we het er inderdaad op houden dat gettext dáár niet geschikt voor is.

[Spider.007]

Ik beaam het ook even gettext is niet bedoeld voor MT applicaties en dus ongeschikt voor website-gebruik. Drop het en schrijf in 5 minuten je eigen alternatief die dit net zo snel en veel beter kan

[robbert]

Verwijderd schreef op zaterdag 15 september 2007 @ 20:26:
Is het overigens zo dat je wel elke keer handmatig de .mo bestanden maakt? Of pas je alleen de .po bestanden aan, en geloof je het verder wel?

Ik genereer telkens nieuwe po bestanden met xgettext, voeg ze samen met de oude versie met msgmerge, vertaal de wijzigingen en geneer mo bestanden met msgfmt.

LauPro schreef op zaterdag 15 september 2007 @ 20:34:
Ok, misschien is de implementatie in PHP goed, maar de non thread safety van gettext (en die van de onderliggende libs) is absoluut onacceptabel.

Wat voor een problemen zou je dan krijgen? Bij een database snap ik dat het nogal link is als het non thread safe is, als 2 threads tegelijkertijd een tabel gaan wijzigen krijg je natuurlijk erg enge dingen. Maar wat voor iets engs kan er gebeuren gezien gettext enkel een bestand leest?

Spider.007 schreef op zaterdag 15 september 2007 @ 20:39:
Drop het en schrijf in 5 minuten je eigen alternatief die dit net zo snel en veel beter kan

Ik kan wel in 5 minuten een alternatief schrijven, maar dan moet ik ook nog iets maken dat autmatisch de taal bestanden (net als xgettext) voor mij genereert en een oud en nieuw taalbestand kan samen voegen (net als msgmerge). Of ik moet natuurlijk een eigen gettext implementatie schrijven..

[LauPro]

Verwijderd schreef op zaterdag 15 september 2007 @ 20:37:
[...]
Ok, PHP wordt meestal gebruik voor webscripting, maar laten we het er inderdaad op houden dat gettext dáár niet geschikt voor is.

Ik vind het echt een hele kwalijk zaak dat deze brakke support door de developers zo wordt gebaggetaliseerd.

De indruk wordt gewekt dat er support is, en die is er uiteindelijk niet. Dit is gewoon een hele grote bug, en er wordt vanuit PHP gewoon niets ondernomen. Wat mij betreft was die gettext support allang uit de repository gedropped.

Dat geldt ook voor glibc overigens, die medeplichtig is.

robbert schreef op zaterdag 15 september 2007 @ 21:06:
Wat voor een problemen zou je dan krijgen? Bij een database snap ik dat het nogal link is als het non thread safe is, als 2 threads tegelijkertijd een tabel gaan wijzigen krijg je natuurlijk erg enge dingen. Maar wat voor iets engs kan er gebeuren gezien gettext enkel een bestand leest?

Dat de verschillende vertaling niet sync zijn. En PHP, gettext en MT zorgen er dan voor dat er soms gewoon niet vertaald wordt (zonder warning of wat dan ook!). En dat is gewoon onacceptabel.

edit: iedereen loopt te mekkeren over 'the free lunch is over' en weet ik het niet allemaal, maar ondertussen worden dit soort wanpraktijken gewoon gedoogd. Ik ben hier gewoon heel simpel in.

[ Voor 38% gewijzigd door LauPro op 15-09-2007 21:40 ]

[BCC]

Dat gettext gecached wordt is juist een feature, aangezien het anders enorm traag wordt. Als je geen 'eigenaar' van de server bent is het cachen inderdaad niet handig, aangezien je dan niet even eenvoudig apache kan schoppen. Gettext is een hele mooie oplossing, maar niet hier. Een server herstarten in een goede webomgeving is mag namelijk nooit echt een issue zijn .

[ Voor 14% gewijzigd door BCC op 15-09-2007 21:43 ]

[kokx]

Gebruik dan gewoon 1 van de al bestaande vertaal alternatieven.

[LauPro]

BCC schreef op zaterdag 15 september 2007 @ 21:41:
Dat gettext gecached wordt is juist een feature, aangezien het anders enorm traag wordt. Als je geen 'eigenaar' van de server bent is het cachen inderdaad niet handig, aangezien je dan niet even eenvoudig apache kan schoppen. Gettext is een hele mooie oplossing, maar niet hier. Een server herstarten in een goede webomgeving is mag namelijk nooit echt een issue zijn .

Cachen is prima maar vernieuw dan wel je cache als hetgene dat je cached wijzigt. In Linux 2.6 zit inode notification waarmee dit prima implementeerbaar is. Cachen totdat het process wordt geherstart is gewoon veel te eenzijdig.

[Spider.007]

robbert schreef op zaterdag 15 september 2007 @ 21:06:
[...]

Ik kan wel in 5 minuten een alternatief schrijven, maar dan moet ik ook nog iets maken dat autmatisch de taal bestanden (net als xgettext) voor mij genereert en een oud en nieuw taalbestand kan samen voegen (net als msgmerge). Of ik moet natuurlijk een eigen gettext implementatie schrijven..

Uiteraard lees je dan gewoon de originele gettext files uit; parse je die met een eenvoudige preg_match en kun je die zelf evt cachen. Ook dat moet niet meer dan 5 minuten kosten

[robbert]

Ik heb maar voorlopig opgelost met een taal bestand met een timestamp erachter. Zo pakt die telkens het nieuwe bestand als ik wijzigingen aan hebt gebracht en haalt die het niet uit de cache. Wat relevante code:

PHP:

$domains = $path.$locale."/LC_MESSAGES/messages*.mo");
if(count($domains)) {
  $current = basename($domains[0],".mo");
  bindtextdomain($current, $path);
  textdomain($current);
}

Dat het niet zo netjes is weet ik.

Ik gebruik overigens wel een wrapper class om de gettext functies heen, iets in de trend van:

PHP:

class T {
function _($text) { 
   return _($text); 
}
}

Dan kan ik later gemakkelijk switchen naar een eigen of andere gettext implementatie. T::_("blaat") ziet xgettext gelukkig ook.

Mocht ik een eigen gettext implementatie schrijven, wat zou dan het handigste manier zijn om te cachen.

• Alle vertalingen in een associatieve array gooien, hier php code van genereren in een bestand gooien en deze telkens laten includen. (Een beetje volgens het idee als dat Smarty doet met template bestanden)
• Ipv er php code van maken het serializen en in een bestand opslaan, en dit telkens inlezen en unserializen.
• Die associatieve array opslaan met Alternative PHP cache
• In $SESSION lijkt me niet echt handig, gezien je dan voor iedere sessie het op moet slaan.

[BCC]

Gettext houdt het in memory. Volgens mij kan je nooit een oplossing in PHP maken die dat efficienter doet. Alternative PHP cache oid icm met een van de je genoemde technieken zou dan prima kunnen, maar ik zou dan eerder meer tijd in gettext stoppen. Dit is een prima en bewezen product, waar veel handige tools voor zijn.

[ Voor 50% gewijzigd door BCC op 21-09-2007 11:03 ]

[Verwijderd]

BCC schreef op vrijdag 21 september 2007 @ 11:02:
Gettext houdt het in memory. Volgens mij kan je nooit een oplossing in PHP maken die dat efficienter doet. Alternative PHP cache oid icm met een van de je genoemde technieken zou dan prima kunnen, maar ik zou dan eerder meer tijd in gettext stoppen. Dit is een prima en bewezen product, waar veel handige tools voor zijn.

En hoeveel ervaring heb jij precies met gettext en een multithreaded omgeving (zoals een HTTP server)? Gettext moet je in zulke situaties gewoon helemaal niet gebruiken, en niet eens overwegen on te gebruiken. Zonde van je tijd.

De snelheid van PHP op het gebied van inlezen van wat tekstbestanden en het opslaan in associatieve array's is best goed, over het algemeen. En als je het parsen dan 1 keer doet, en in het vervolg overslaat door de complete array's te cachen, dan durf ik best te beweren dat de performance best goed is.

[ Voor 28% gewijzigd door Verwijderd op 21-09-2007 11:17 ]

[BCC]

Verwijderd schreef op vrijdag 21 september 2007 @ 11:10:
[...]

En hoeveel ervaring heb jij precies met gettext en een multithreaded omgeving (zoals een HTTP server)? Gettext moet je in zulke situaties gewoon helemaal niet gebruiken, en niet eens overwegen on te gebruiken. Zonde van je tijd.

De snelheid van PHP op het gebied van inlezen van wat tekstbestanden en het opslaan in associatieve array's is best goed, over het algemeen. En als je het parsen dan 1 keer doet, en in het vervolg overslaat door de complete array's te cachen, dan durf ik best te beweren dat de performance best goed is.

Die zelfde vraag kan ik ook aan jouw stellen, maar goed. Ten eerste is een HTTP server geen multithreaded omgeving, maar worden er parallel sequentiele opdrachten afgehandeld. Als dat niet kan heb je een schalingsprobleem, maar dat is wat anders. Gettext is loei simpel. Key String in => Result string uit. Dit is in een hash die in memory is en dus enorm snel is. Ik heb ervaring met een aantal grote webapplicaties die dit op deze manier prima doen. Natuurlijk kun je zelf prima nog een keer het wiel uitvinden door een PHP hash in memory te gebruiken. Zou het performen? Ja, ik denk het wel. Zijn er vertalers te vinden die begrijpen hoe ze vertalingen moeten aanleveren voor jouw systeem? Ik denk het niet. Po/Mo contructies zijn erg bekend onder vertalers. Zaken als textdomans, fallbacks e.d. zijn perfect geregeld. Ook is bewezen dat het schaalt en bewezen dat het perfect werkt. Waarom zou je zelf een hoop moeite doen als er prima oplossingen voorhanden zijn?

[ Voor 16% gewijzigd door BCC op 21-09-2007 11:39 ]

[Erkens]

Verwijderd schreef op vrijdag 21 september 2007 @ 11:10:
En hoeveel ervaring heb jij precies met gettext en een multithreaded omgeving (zoals een HTTP server)? Gettext moet je in zulke situaties gewoon helemaal niet gebruiken, en niet eens overwegen on te gebruiken. Zonde van je tijd.

Ik heb nog nooit problemen ondervonden met gettext binnen een grote webapplicatie die door veel mensen gelijktijdig gebruikt wordt in diverse talen.

De snelheid van PHP op het gebied van inlezen van wat tekstbestanden en het opslaan in associatieve array's is best goed, over het algemeen. En als je het parsen dan 1 keer doet, en in het vervolg overslaat door de complete array's te cachen, dan durf ik best te beweren dat de performance best goed is.

alleen jammer van het geheugenverbruik, zeker als je veel teksten hebt...