WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#19852 closed task (blessed) (fixed)

Don't load admin strings on the frontend

Reported by: nacin Owned by:
Milestone: 3.4 Priority: normal
Severity: normal Version:
Component: I18N Keywords:
Focuses: Cc:

Description

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.

Attachments (9)

19852-makepot.diff (3.6 KB) - added by ryan 2 years ago.
19852-makepot.2.diff (3.6 KB) - added by ryan 2 years ago.
Untested makepot.php patch
19852-makepot.3.diff (3.6 KB) - added by ryan 2 years ago.
Now with testing, but not much.
19852-makepot.4.diff (4.4 KB) - added by ryan 2 years ago.
With some fixes
19852-makepot.5.diff (4.8 KB) - added by ryan 2 years ago.
User and site admin in same pot. Dupe removal for net admin pot.
19852.diff (1.4 KB) - added by ryan 2 years ago.
First pass at loading the new mo files
19852.2.diff (1.4 KB) - added by ryan 2 years ago.
ms- back compat. Load admin-network- instead of network-admin-
19852.3.diff (1.5 KB) - added by ryan 2 years ago.
Now with less bugs
load_default_textdomain.diff (1.4 KB) - added by nacin 2 years ago.

Download all attachments as: .zip

Change History (46)

comment:1 ryan2 years ago

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

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

comment:2 scribu2 years ago

  • Cc scribu added

comment:3 ocean902 years ago

  • Cc ocean90 added

ryan2 years ago

ryan2 years ago

Untested makepot.php patch

comment:4 ryan2 years ago

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.

comment:5 ryan2 years ago

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

comment:6 pavelevap2 years ago

  • Cc pavelevap@… added

comment:7 ryan2 years ago

> 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.

comment:8 follow-up: pavelevap2 years ago

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.

ryan2 years ago

Now with testing, but not much.

comment:9 ryan2 years ago

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.

Last edited 2 years ago by ryan (previous) (diff)

comment:10 nacin2 years ago

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

comment:11 in reply to: ↑ 8 nacin2 years ago

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.

comment:12 pavelevap2 years ago

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.

Last edited 2 years ago by pavelevap (previous) (diff)

comment:13 ryan2 years ago

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.

ryan2 years ago

With some fixes

ryan2 years ago

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

ryan2 years ago

First pass at loading the new mo files

comment:14 nbachiyski2 years ago

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

comment:16 ryan2 years ago

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.

ryan2 years ago

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

ryan2 years ago

Now with less bugs

comment:17 ryan2 years ago

In [19772]:

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

comment:18 Chouby2 years ago

  • Cc frederic.demarle@… added

comment:19 nacin2 years ago

In [19787]:

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

comment:20 nacin2 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:21 pavelevap2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:22 ryan2 years ago

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.

comment:23 pavelevap2 years ago

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

comment:24 ryan2 years ago

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.

comment:25 pavelevap2 years ago

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...

comment:26 ryan2 years ago

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'
Last edited 2 years ago by ryan (previous) (diff)

comment:27 ryan2 years ago

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.

Version 0, edited 2 years ago by ryan (next)

comment:28 pavelevap2 years ago

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...

comment:29 follow-up: nacin2 years ago

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.

comment:30 in reply to: ↑ 29 pavelevap2 years ago

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...

comment:31 follow-up: nacin2 years ago

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.

comment:32 pavelevap2 years ago

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...

comment:33 ryan2 years ago

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.

comment:34 in reply to: ↑ 31 pavelevap2 years ago

  • 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?

comment:35 ryan2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:36 follow-up: pavelevap2 years ago

OK, should I create new ticket?

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

comment:37 in reply to: ↑ 36 nacin2 years ago

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.

Note: See TracTickets for help on using tickets.