Opened 13 years ago
Closed 11 years ago
#20882 closed task (blessed) (fixed)
Remove strings related to Akismet from WP localization files
Reported by: | pavelevap | Owned by: | |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | 2.0 |
Component: | I18N | Keywords: | |
Focuses: | Cc: |
Description
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.
Change History (11)
This ticket was mentioned in IRC in #wordpress-dev by netweb. View the logs.
11 years ago
#5
in reply to:
↑ 3
@
11 years ago
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.
#6
@
11 years ago
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 :)
#7
@
11 years ago
- Keywords dev-feedback removed
- Milestone changed from Awaiting Review to 3.9
- Type changed from defect (bug) to task (blessed)
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 afterinit
. I'd recommend only doing this onadmin_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.
#8
@
11 years ago
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.)
#9
@
11 years ago
Added text domain support to plugin
https://plugins.trac.wordpress.org/changeset/878668
https://plugins.trac.wordpress.org/changeset/878796
#10
@
11 years ago
@eoigal Also this -> #Plugins2176: Fix variable in string text domain
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
akismet
in wordpress.potakismet
in wordpress-admin.potdev-feedback
addedWould 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?