[wp-hackers] wordpress.org *.pot file feature for pluginsgetsbroken by PoEdit
nb at nikolay.bg
Tue Jul 21 16:18:18 UTC 2009
On Mon, Jul 20, 2009 at 16:14, <heiko.rabe at code-styling.de> wrote:
> I know this. But the point is, that a lot of translation frameworks only based on normal gettext capabilities and also assume, that a rescan process can run every time on demand if required.
> Out of this scope this breaks all arround based on normal gettext behavoir.
> Any msgid not having a line number/file reference and can't be found by the gettext function definitions will be declared as obsolete.
We can add line numbers if this causes a problem with the tools.
> I know, that this has been born out of the need, that inactive plugins should be translatable too. But the way they the translated is also not best case. In a loop the language files will be load (and will reside in memory after translation the fields nevertheless). As you may know a 300kb WordPress main file will consume on servers upto 4MB! PHP memory, the leads to a mutiplier of 10 - 12!
> How you explain to users/customers, that they exceed there PHP memory limit every time they try to load the plugin overview page ?
A typical WordPress install runs on 32 or 64M of memory. The plugins
page consumes about 11M with locale en_US and about 10 inactive
plugins. You can do the math from now on. How many and how big plugin
translations would it take to fill all the memory?
> This are only a subset of issues. I never want to trash this feature but a more sophisticated solution is required than this one or you have a lot of trouble in consulting/helpdesk to explain that this is a big design issue of WordPress itself!
Heiko, I understand your worries, but this was the most practical
solutions of all we looked at.
More information about the wp-hackers