Hi list, A few years ago I wrote some C++ tools to extract strings from templates, generate .po files, merge .po files and build static templates using these po files
Everything worked like a charm and I still use a fork of this work to handle some of my haxe templates internationalization (without i18n attributes since I was bored of using them:). You will find the code here : https://svn.motion-twin.com/phptal/phptal_i18n/trunk/cpp/ And I think I already posted some documentation about these tools on this list. Feel free to use, modify, port to php, etc :) Best regards Laurent On 10 April 2010 13:21, Florent <floc...@free.fr> wrote: > Robert Goldsmith <rgoldsm...@...> writes: > >> >> As part of my integration into Zend Framework, I wrote a replacement > translator service for phptal. you >> basically just write a class that implements PHPTAL_TranslationService and > then when you create the >> phptal instance you call its 'setTranslator' method and pass in an instance >> of > your class. >> >> I assume that the translator service is not actually called at compile time - > only at runtime. Obviously if >> you use something like Zend you can make use of memcache to hold the > translation keys in a cache (which works >> very well) but translating static text at compile time (if it doesn't already > happen) would require >> deeper modification of phptal. >> >> As an aside, I also make use of Zend's plural support and use a custom tales > modifier to pass in the >> translation keys for singular and plural and then the variable with the value > used to decide on the actual >> key to use. It works very well for me :) >> >> Robert >> > > > Hi Robert, > > Gettext translation being already loaded in memory, I suppose there's not much > difference calling gettext method rather than fetching variables from memcache > or other shared memory system. > When it comes to complex templates, I assume it would save some memory > and CPU cycles to have a already translated static template at run time. > I presume that indeed there's heavier work as some part of > phptal has to be rewritten. > Maybe Kornel could advise on what would be the best entry point > to modify phptal behaviour? > I also read on that thread : > http://lists.motion-twin.com/pipermail/phptal/2005-October/000479.html > that laurent, the initiator of phptal project did some work on > what i'm trying to achieve. > Wouldn't be some interesting way of improving phptal in futures evolutions? > > Thanks in advance for your input guys. > > Cheers > > > _______________________________________________ > PHPTAL mailing list > PHPTAL@lists.motion-twin.com > http://lists.motion-twin.com/mailman/listinfo/phptal > -- Laurent Bédubourg lbedubo...@motion-twin.com http://www.motion-twin.com _______________________________________________ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal