WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#19831 closed defect (bug) (wontfix)

Multisite strings in standard translation

Reported by: pavelevap Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3.1
Component: I18N Keywords:
Focuses: Cc:

Description (last modified by nbachiyski)

There are many strings which are related to Multisite version, but they are part of standard WordPress localization files. Any chance to move them to proper ms-locale.mo file? It would be better for translators and also users (less strings = less memory used). Only a few percentage of users need Multisite version, so there is no need for every standard WordPress user to automatically load all these strings, I guess...

Change History (18)

comment:1 ocean902 years ago

  • Keywords reporter-feedback added

There are many strings

Which are?

comment:2 pavelevap2 years ago

Examples:

menu.php: "My Sites", "Network Setup", "Delete Site"

users.php: "Remove allows you to remove a user from your site. It does not delete their posts. You can also remove multiple users at once by using Bulk Actions."

These strings can be seen only when Multisite is enabled.

I can create the whole list (about 50 - 100 strings), but I am not sure if it is possible to solve it somehow? For multisite translation is loaded ms-locale.mo file, but strings have no ms textdomain, so I suppose that there is any automatic localization script on files in wp-admin/network directory?

comment:3 ocean902 years ago

  • Keywords reporter-feedback removed

In load_default_textdomain():

if ( is_multisite() || ( defined( 'WP_INSTALLING_NETWORK' ) && WP_INSTALLING_NETWORK ) ) {
    load_textdomain( 'default', WP_LANG_DIR . "/ms-$locale.mo" );
}

And WP_INSTALLING_NETWORK is defined in wp-admin/network.php.

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

comment:4 pavelevap2 years ago

So, it should work as expected, but only strings are in different file? These strings have usually condition if ( is_multisite() ) so they should be loaded from ms-locale.mo file. But because they are not marked somehow in code (for example with textdomain), then .pot generator adds them into standard localization file and they are loaded everytime for all users. Is there any solution? Adding ms textdomain to all strings?

comment:5 ocean902 years ago

See #13565 for background.

comment:6 pavelevap2 years ago

Thank you, I did not notice that ticket. There was not enough time during beta, so strings were not marked with textdomain, but loaded conditionally. And .pot generator is not smart enough to select all multisite strings for ms-locale.pot file. So should it be solved on the side of generator or adding special ms textdomain?

comment:7 wet2 years ago

  • Cc r.wetzlmayr@… added

comment:8 DrewAPicture2 years ago

  • Cc xoodrew@… added

comment:9 knutsp2 years ago

  • Cc knut@… added

comment:10 nacin2 years ago

We would need to do this in two ways:

One, mark any multisite-only strings with a special textdomain, such as 'multisite'.

Two, have the .pot generator avoid those strings when building the core pot, and merge them into the multisite pot.

Then the strings would fall back to the default textdomain (into which ms-$locale.mo is merged) and everything would be peachy.

What do the modifications to the pot generator look like? It may be found here: http://i18n.svn.wordpress.org/tools/trunk/makepot.php.

comment:11 ocean902 years ago

Related: #19852

comment:12 Chouby2 years ago

  • Cc frederic.demarle@… added

comment:13 nacin2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Going to close this as wontfix for now, as #19852 took core in a different approach.

comment:14 follow-up: pavelevap2 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I have to reopen this ticket, because changes in 19852 worsened this problem (data from GlotPress):

  • WP 3.3.1 - 3491 (standard), 482 (multisite)
  • Trunk - 1644 (frontend), 2194 (backend), 260 (multisite admin)

So, in WP 3.3.1 there were 3491 standard strings loaded in administration. But in current trunk this number was radically increased to 3838 (1644 + 2194) strings (!). Specially for multisite was loaded 482 strings (and I wanted to increase this number), but now there are only 260 strings. It is too bad for localized versions, much more memory and no sense to load things which are not needed for most users...

Yes, change in 19852 is very positive for loading only frontend strings, but really problematic for working in backend. I think the best approach would be marking all multisite strings with special textdomain which could lead to increase in multisite strings to more than 600.

comment:15 SergeyBiryukov2 years ago

  • Milestone set to Awaiting Review

comment:16 in reply to: ↑ 14 nbachiyski2 years ago

  • Description modified (diff)

Replying to pavelevap:

I have to reopen this ticket, because changes in 19852 worsened this problem (data from GlotPress):

  • WP 3.3.1 - 3491 (standard), 482 (multisite)
  • Trunk - 1644 (frontend), 2194 (backend), 260 (multisite admin)

So, in WP 3.3.1 there were 3491 standard strings loaded in administration. But in current trunk this number was radically increased to 3838 (1644 + 2194) strings (!). Specially for multisite was loaded 482 strings (and I wanted to increase this number), but now there are only 260 strings. It is too bad for localized versions, much more memory and no sense to load things which are not needed for most users...

Yes, change in 19852 is very positive for loading only frontend strings, but really problematic for working in backend. I think the best approach would be marking all multisite strings with special textdomain which could lead to increase in multisite strings to more than 600.

Strings shouldn't be duplicated in the backend. The admin strings are also loaded in the default textdomain and during the loading procedure the new and old values are merged, not appended to each other.

Do you have any specific tests to show that the memory usage increased, because of that change?

comment:17 pavelevap2 years ago

There is no problem with string duplication, I guess. In administration will be loaded default localization file + admin file and due to changes in 19852 it will lead to specified increase.

I did not make any tests yet, but differences between original and localized version in WP 3.3.1 were usually 6 - 8 MB. So when there will be string increase of 10 %, then I would expect the same increase in memory needed (0,5 - 1 MB). Too bad for localized versions, especially when these strings are not needed.

The main purpose of this ticket was to DECREASE number of loaded strings which are NOT needed by most of users. That means multisite strings which were loaded by default. But the only way to achieve this is marking these strings with multisite textdomain. So, I hoped, that there will be autogeneration based on some directories (as it was in WP 3.3.1 - 482 strings) + strings which are located throughout other files, but we can find them and mark them with multisite textdomain (estimated cca 100 strings). So there could be less strings loaded in the end. But now (based on changes in ticket 19852) there is important increase of loaded strings. Instead of estimated decrease somewhere to 3400 strings, we have 3838 strings (!) now.

comment:18 ryan2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

This can be debated on #19852. Closing again to avoid splitting the discussion.

Note: See TracTickets for help on using tickets.