Remove strings related to Akismet from WP localization files

[pavelevap]

There were several tickets (#19832, #19597) related to this issue, but we had to miss it somehow for 3.4.

Main purpose of this ticket is removing all strings related to Akismet from localization files. All strings (about 110) are loaded (mainly on frontend) even if Akismet is not active. Akismet can have its own localization file.

[netweb]

Thanks for the report pavelevap. Sorry you never got a response. ​#FridayTracSprint

Still valid today. No ​open tickets for Akismet to add translations to it's own project.

Akismet would need a new GlotPress project at ​http://translate.wordpress.org/projects

Akismet Source: ​https://plugins.trac.wordpress.org/browser/akismet/#assets

• ~123 references to akismet in ​wordpress.pot
• 2 references to akismet in ​wordpress-admin.pot

dev-feedback added

Would removing Akismet translations into their own translation project be beneficial for WP core?
Or is it easier/simpler to leave what is no doubt a very popular plugin translated in core?

[pavelevap]

Replying to netweb:

Would removing Akismet translations into their own translation project be beneficial for WP core?
Or is it easier/simpler to leave what is no doubt a very popular plugin translated in core?

Yes, it would be very beneficial. Akismet is commercial project (plugin) and in our country not used by majority of users. But all WordPress users have to load all translations and use their memory_limit for loading something which is not needed. I hesitate to removing all translated strings from our translation, because it would be beneficial for majority users (but other users would be without localization).

I have no problem to include Akismet translation in the whole localized package (even if it is commercial project), but please, make a special textdomain and load it only for users which are really using this plugin.

[netweb]

Thanks for the reply pavelevap, I see where your coming from now :)

Just as included themes are are a 'sub-project' of core Akismet should also be a 'sub-project' of core listed under ​http://translate.wordpress.org/projects/wp/dev and only load the Akismet translations if the plugin is activated.

Hopefully in the not to distant future a core dev can add some more feedback :)

[nacin]

Akismet 3.0, which will ship around the same time as WordPress 3.9, has a 20-25% increase in strings. At 173 strings, it's a full 10 percent of all frontend strings, which surprised me. It's time for this to happen.

Akismet will need to:

• Add an "akismet" textdomain to all of its strings. There is a handy CLI tool in develop.svn for this (it is also accessible via ​http://wordpress.org/plugins/{plugin-name}/admin).
• Add a "Text Domain: akismet" header to akismet.php.
• Add a load_plugin_textdomain( 'akismet' ) call on or after init. I'd recommend only doing this on admin_init and then also on the frontend when needed (such as when rendering a widget). I imagine beyond widgets (which most sites won't use), Akismet doesn't do anything on the frontend.

They have it easy. :-) I will need to:

• Update the POT harvesting scripts to exclude wp-content/plugins/akismet from WordPress, and to treat it as a standalone plugin.
• Create a new Akismet project on translate.wordpress.org, and have the harvesting scripts populate this project.
• Transfer all existing translations from WordPress to the new project. That will cover perhaps half of the strings in 3.0, depending on how far along translators get between now and then. (Point is, translator effort is not wasted.)
• Set up language pack harvesting for Akismet. Basically, any completed locale will start serving strings to Akismet 3.0-alpha or later, to WordPress 3.7 or greater.
• Add wp-content/languages/plugins/akismet-$locale.po/mo by default to international zips, so an initial install doesn't require a separate language pack download (unless out of date). We already do this for bundled themes.

[nacin]

Worth pointing out that:

• Akismet doesn't need to bother generating and committing a POT file if it doesn't want to. It can choose to have potbot do it for them, or it doesn't need to be committed anywhere.

• Adding a text domain will break translations for pre-3.7 installs. I don't find that to be a major issue. As it is, Akismet 3.0 will break half of translations, and already, Akismet updates since the user's WP version will have started to shift more to English. (There is a way around this — the text domain can be a constant that is set to 'akismet' or 'default' based on the WP version, but it's probably more expended effort than necessary.)

[eoigal]

Added text domain support to plugin

​https://plugins.trac.wordpress.org/changeset/878668
​https://plugins.trac.wordpress.org/changeset/878796

[netweb]

@eoigal Also this -> ​#Plugins2176: Fix variable in string text domain

[nacin]

Everything outlined in my comment above is completed.

Language pack harvesting will occur within a week or so once more languages have translated it and we have scripts in place.