[wp-hackers] wordpress.org *.pot file feature for pluginsgetsbroken by PoEdit

[heiko.rabe at code-styling.de]

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. 

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!

Now lets say, you are having 70 plugins and 20 are currently active. Lets also say, that they have an average of 30kb language file.

= 30kb * multiplier * 70 = 24.6 MB 

wasted by processing this translations this way.
How you explain to users/customers, that they exceed there PHP memory limit every time they try to load the plugin overview page ?

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!


>You can download (via svn) the scanner from here (I'm sure it has an intro
>page somewhere):

>http://svn.automattic.com/wordpress-i18n/tools/trunk

>and use it before commiting a plugin.


>> In my opinion this is not a compromise, because i didn't want first to
>> commit my plugin, afterwards create to *.pot and than build my german
>> translation and have to repeat again a commit.
>> This is annoying work.
>> It must be scannable by gettext processors anyway without loosing
>> informations, imo.
>>
>>>This is the reason that plugin authors provide a .pot file generated with
>>>the custom WP scanner. It's not a perfect solution, but it's a good
>>>compromise, imo.