Don't load admin strings on the frontend

[nacin]

We should take the same approach as we did for multisite strings, and only load admin strings in the admin.

This should be handled in load_default_textdomain(). Additionally, includes/admin.php should load the admin mo file if it is not already loaded, in the case of the frontend calling on the admin bootstrap (which we, for example, do in admin-ajax).

This came out of #19832.

[ryan]

Here's a link to makepot.php for those not familiar with it:

​http://i18n.trac.wordpress.org/browser/tools/trunk/makepot.php

[ryan]

Untested makepot.php patch

[ryan]

Patch (totally untested) creates frontend, site admin, network admin, and user admin pots. The ms pot is dropped since it accounts for so few strings. The continents-cities pot is preserved.

[ryan]

Here are the new pots and their corresponding number of lines. The user admin pot has only two translatable strings.

• wordpress-network-admin.pot: 1122
• wordpress-site-admin.pot: 10634
• wordpress-user-admin.pot: 20
• wordpress.pot: 6701

[ryan]

> grep msgid wordpress-site-admin.pot | wc -l
2460

A fair number of strings. 1552 for wordpress.pot and 259 for wordpress-network-admin.pot.

[pavelevap]

I think that there will be special textdomain needed, which have to be manually added to particular strings?

Example:

wp-includes/general-template.php:

1) function register_admin_color_schemes() - contains strings for administration.

2) function get_search_form() - contains strings for frontend.

And other problem: Some general strings are same for frontend and backend, for example "Comments", etc. So, there will be need for adding them to both textdomain files.

[ryan]

Now with testing, but not much.

[ryan]

The pots will be merged where necessary. Network admin, for example, will load and merge wordpress-network-admin.pot, wordpress-site-admin.pot, and wordpress.pot.

[nacin]

Let's reduce it by one and end up with wordpress.pot, wordpress-admin.pot, and wordpress-admin-network.pot?

[nacin]

Replying to pavelevap:

1) function register_admin_color_schemes() - contains strings for administration.

All strings in wp-includes will be included in the main wordpress.pot, regardless of intended use. It won't add up to much.

And other problem: Some general strings are same for frontend and backend, for example "Comments", etc. So, there will be need for adding them to both textdomain files.

As there will be a hierarchy of includes (wordpress.pot is always included, wordpress-admin.pot is always included in the site/network/user admins, etc.) we can keep the string in only one pot, whichever is the superset.

[pavelevap]

But then there will be also many strings from admin loaded on frontend. Main purpose of this ticket was to minimize strings loaded on frontend. And now there will be also mess for translators - some admin strings together with all frontend strings. There was another ticket related to multisite strings: ​http://core.trac.wordpress.org/ticket/19831

There is only one good way - marking all frontend strings manually with special textdomain, I guess.

[ryan]

The current makepot patch removes thousands of strings from the frontend pot. register_admin_color_schemes() and the handful of others that introduce backend only strings into the frontend are not worth worrying about.

[ryan]

With some fixes

[ryan]

User and site admin in same pot. Dupe removal for net admin pot.

[ryan]

First pass at loading the new mo files

[nbachiyski]

The patch looks good to me, except the call to non-existant $this->wp_user_admin($dir, null); in wp_core().

[ryan]

​http://i18n.trac.wordpress.org/changeset/19029

[ryan]

Next up is updating all of the potbot related scripts, creating new GlotPress projects for the new pots, and moving strings to the right projects.

[ryan]

ms- back compat. Load admin-network- instead of network-admin-

[ryan]

Now with less bugs

[ryan]

In [19772]:

Load the new admin and network admin mo files, if present. see #19852

[nacin]

In [19787]:

Load admin-$locale.mo in setup-config.php. see #19852, see #18180.

[nacin]

Next up is updating all of the potbot related scripts, creating new GlotPress projects for the new pots, and moving strings to the right projects.

We're all done here.

[pavelevap]

I have to reopen, because this solution is good for loading frontend strings, but very bad for administration. For localized versions there is huge increase of loaded strings in administration (cca + 10 %). Please see my comment here: ​http://core.trac.wordpress.org/ticket/19831#comment:14

Localized versions had sometimes issues with 32 MB memory_limit and now it will be even worse... This should be solved before string freeze.

[ryan]

With trunk running in a single site configuration I get 3527 strings loaded for an admin page load. With 3.3 running single site I get 3491 strings loaded for an admin page load. This 1% difference is explained by new strings in trunk and the small number of multisite strings in wp-includes that are now loaded for single site.

[pavelevap]

But in GlotPress there are 1659 strings for frontend and 2184 for admin, that means 3843 strings for translation (for trunk).

[ryan]

Losing the ms po adds around 200 ms related strings to a single site admin page load, most of which are short error messages for the signup API. That doesn't really bother me. The bulk of the additional strings in 3.4 are due to the customize UI.

[pavelevap]

Yes, problem is in around 220 strings which will be loaded on ALL localized sites in WP 3.4. And all these strings will have to be translated by voluntary translators (they will not know about fact, that most of users will never see these strings). All these strings will increase memory_limit usage, localization files size, etc. Some strings may be short and not so important. But is it really neccessary to load them on all localized websites?

Also ticket 19831 - ​http://core.trac.wordpress.org/ticket/19831 was founded because there are other (around 100 strings) which should be moved to multisite. So, in the end there could be significant decrease of around 350 strings (10 %) which could be loaded only for real multisite sites.

We have many users with memory and slowness issues, for example WP 3.3.1 original website uses 26,05 MB, but localized one uses 35,53 (standard Dreamhost account, fresh install). And that is why this issue really bothers me...

[ryan]

Some numbers:

• 265 strings in 'ms-.*', '.*/ms-.*', '.*/my-.*', 'wp-activate\.php', 'wp-signup\.php', 'wp-admin/includes/ms\.php', 'wp-admin/includes/class-wp-ms.*'

• 136 strings in 'ms-.*', 'wp-includes/ms-.*', 'wp-activate\.php', 'wp-signup\.php'
• 65 strings in 'wp-activate\.php', 'wp-signup\.php'
• 123 strings in 'wp-activate\.php', 'wp-signup\.php', 'wp-login\.php'

[ryan]

So, we have 136 ms specific strings in the frontend pot and 129 in the admin pot. That's without eliminating of duplicates, which would save a handful of strings.

[pavelevap]

Yes, but in 3.3.1 there were much more multisite strings (482). But they were probably moved to general frontend file? Or where did these strings (more than 200) gone?

There are also many other strings (usually very long - help text, confirmation email, etc) which can be found throughout core files. Some examples (only searching for is_multisite() in several files to find some of them):

/wp-admin/users.php: 2
/wp-admin/user-new.php: 12
/wp-admin/user-edit.php: 4

Is it possible to mark them for example with special multisite textdomain? Then these strings can be easily located (and .pot generated) and loaded only for real multisite websites. It is not problem that we will not find all of them for 3.4. We will find most of them and we can improve (complete) it in future. It would be really improvement for translators (no need to translate not needed strings) and mostly for users (load only needed strings). Conditional loading is a good practice, I guess...

[nacin]

Or where did these strings (more than 200) gone?

They went to the network admin POT.

Is it possible to mark them for example with special multisite textdomain?

This is not feasible at the moment with our existing tools or code. One, we currently merge multisite strings into the main pot, while this would result in strings ending up in a separate textdomain, and would therefore not be translated. We'd have to carefully treat the separate textdomain as an alias for the main textdomain.

Two, our ​extraction tools currently ignore textdomains. They just extract all of the strings they find and add them to a pot. Textdomains are for run-time only.

And since the benefit is rather meager, it's not really worth it to go through the trouble of all of this at the moment.

[pavelevap]

Or where did these strings (more than 200) gone?

They went to the network admin POT.

I am not sure if I understand. There were 482 strings for multisite (3.3.1), 265 went to the network admin .pot file. But where are remaining strings (around 220 strings)?

Ad one) Multisite strings could be also merged? So, load main localization file everytime and multisite only when needed?

Ad two) OK, understand, I am not experienced enough to estimate how hard would be this task.

It does not look as great benefit from developer point of view, but translators and users of localized versions would really appreciate it :-( I mentioned especially memory problems...

[nacin]

I am not sure if I understand. There were 482 strings for multisite (3.3.1), 265 went to the network admin .pot file. But where are remaining strings (around 220 strings)?

They are in either wordpress.pot, wordpress-admin.pot, or wordpress-admin-network.pot.

I mentioned especially memory problems...

But we've already made some major improvements here. Multisite added a bit to both, but the frontend is still a major improvement. 100 extra strings in wordpress.pot and 100 extra strings in wordpress-admin.pot are not a big deal in terms of performance or translator efforts.

Ryan and I suggest we declare what our priority is. For that, we suggest: improve frontend performance, with a focus on single-site. What we can possibly do is this:

• Move wp-login.php strings to wordpress-admin.pot and load wordpress-admin.pot on wp-login.php.
• Create a single wordpress-ms.pot that contains 136 strings from wp-includes MS, wp-activate, and wp-signup.
• Leave any multisite strings in wordpress-admin.pot (about 130), as that is not our priority at the moment.

[pavelevap]

When there could be identified 482 strings for multisite in 3.3.1, why there are only 265 multisite strings in current trunk? I understand that they were probably splitted into other files (admin or frontend), but could we return them back? Now there is frontend, admin and multisite admin. What about frontend, admin and multisite (frontend + admin)?

I am really happy with performace improvements, but they are applied only to frontend. On the other side, using WP admin will be performance downgrade and that is why I noticed memory_limit problems (which are very common for localized versions). In 3.3.1 were 3491 strings loaded (single admin site), but in current trunk there are 3838 strings (1644 frontend + 2194 admin) loaded. Frontend performance was improved, but using WP admin worsened by 10 % for single site. So, I wanted to move strings back to multisite and not load them for single site...

[ryan]

269 strings are now in the network admin pot, which is not loaded for single site. There are 265 multisite strings that were in the ms pot before but are now in either the frontend (136) or admin (129) pot. Trunk adds lots of new admin strings that apply to both single and multisite.

[pavelevap]

• Move wp-login.php strings to wordpress-admin.pot and load wordpress-admin.pot on wp-login.php.

Yes, there would be less strings for frontend, but I am not sure if it is needed. There were more than 2000 strings removed from frontend, so moving some others is a good idea, but it is not such a pain as increased total number (frontend + admin).

• Create a single wordpress-ms.pot that contains 136 strings from wp-includes MS, wp-activate, and wp-signup.

Yes, it would be helpfull, but another localization file and another GlotPress project is not so fine for translators. What about adding these strings to current multisite admin? And rename multisite admin to only multisite? So, all multisite strings would be loaded also on frontend?

There are 265 multisite strings that were in the ms pot before but are now in either the frontend (136) or admin (129) pot.

Yes, this is the main problem (regression). Is it possible to move these strings back to only multisite installations (and load for example all multisite strings on frontend and backend)? There are up to 500 strings total, so it is not such a pain. Or at least 129 strings from admin pot can be moved back to multisite admin pot?

[ryan]

Going with what we have. Can consider refinements in the next release.

[pavelevap]

OK, should I create new ticket?

I will make some memory tests during localization of WP 3.4.

[nacin]

Replying to pavelevap:

OK, should I create new ticket?

I will make some memory tests during localization of WP 3.4.

Yes, and that would be great. We would expect the memory of the admin to go up slightly, but to drop pretty significantly on the frontend. This is a good trade-off, and we can consider some further improvements in 3.5.