Multisite strings in standard translation

[pavelevap]

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

[ocean90]

There are many strings

Which are?

[pavelevap]

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?

[ocean90]

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.

[pavelevap]

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?

[ocean90]

See #13565 for background.

[pavelevap]

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?

[nacin]

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.

[ocean90]

Related: #19852

[nacin]

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

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

[nbachiyski]

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?

[pavelevap]

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.

[ryan]

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