Put multisite strings in a separate pot file

[jottlieb]

It's good, that the WordPress help function is going to be real useful (see ticket #13467 for example), but that's gonna increasing the size of language files for l10n very much.
So please: Put the help texts in a special language file, which users can disclaim, if they want to (like the continent_cities.po/mo).

There already is the problem of exhausted PHP memory because of using a language file (e.g. the German one). Putting a lot of long texts into the normal WordPress .pot will make it go even worse.

[nacin]

Using a second textdomain is worth considering.

With regards to package size: #13307. This problem hit us in 3.0 beta but apparently it had festered in i18n packages for some time. I'm surprised we're only now hearing reports of memory exhaustion from translators -- second off-handed mention of it I've seen this week -- which is kind of frustrating, as we could have implemented stopgaps in earlier versions of WordPress.

[jane]

@jottlieb: By changing the owner to yourself, you've basically made it so the i18n lead won't see your ticket in his assignment queue. Please don't assign yourself as the owner of a ticket unless you are coding the patch and have discussed it with the lead devs. Reassigning to Nikolay so he can weigh in, but it would need to be quick, as we're planning RC for tomorrow.

[jottlieb]

Let me give you some numbers: Using a language file can easily increase the PHP memory consumption up to 4 to 10 MB. So using second (or third) textdomain is really worth considering.
But don't worry. I don't expect that this has to be solved in 3.0 yet.

@jane:
Sorry, I did the reassignment by accident.

[nacin]

Ah, I'm referring to package size memory consumption (#13307), not memory consumption by running translations in general.

[westi]

I'm not sure I like this idea.

For continents/cities it makes much more sense to not translate most of the strings as for the particular locale you are working on only a few of them make sense.

For the help text we really want to see it all translated - yes it may take some time for this to happen but I don't think we should relegate it to an optional translation.

[nbachiyski]

I will do some test about what impact do the help texts have on memory consumption and I will report back.

[nacin]

We also only load the continents/cities mo file on options-general, when we call wp_timezone_choice(). In this case, we'd need to load it on most admin pages. And as westi said, we do want to see it all translated, we don't want to make it optional.

[jottlieb]

@nacin:
We already do translate the help texts, that is not the problem. But in my and some other people opinion, it would be great to have the choice to choose, if translated help texts should be loaded. Heavy Users won't need them.

[infected]

I 100% agree to jottlieb. There's definitely a need to source out the helptext to a separate file. Maybe it doesn't regard you en/us users because you're not using the language files but here's a quick example:

WP 2.9.2 with de_DE language file and 9 activated plugins on a 32bit server OS -> 44% usage of the servers memory limit (40M)

WP 3.0 beta 2 with de_DE language file (from 2.9.2) and 0 (zero) plugins on a 64Bit server OS -> 48% usage of the servers memory limit (64M).

Do you could imagine how much memory WP will use with the fully translated language file? Don't forget: There are no plugins activated... Maybe WP 3.0 need around 55-60% of the servers memory just for the system and it's translation?! That can't be a good solution. So please think about splitting the language file.

[ryan]

Why pick on the help text though? They're a drop in the bucket compared to all of the new MS strings.

[ryan]

More useful would to put strings from all MS specific files into their own pot.

[ryan]

Nikolay will investigate moving all multisite specific strings into their own pot. That will save far more space than moving around help text, and it is easier to conditionally load.

[ryan]

Keep in mind also that the default and classic themes and the importers are no longer in the WP catalog.

[jottlieb]

Sourcing out the MS specific strings is also not a bad idea.

[nbachiyski]

(In [15053]) Load multisite strings POT file only on multisite requests. Fixes #13565

[nbachiyski]

For completeness, the message to wp-polyglots: ​http://lists.automattic.com/pipermail/wp-polyglots/2010-May/004515.html

[nbachiyski]

The result of the ordeal: the memory needed for translations was reduced with about 15%.

[demetris]

Thanks for this, Nikolay. It think it was worth the trouble, and it brings some other advantages too, in addition to memory management:

First, translators can now manage their work easier. For example, a translator could focus on finishing the single-site strings first, and then move on to the multi-site ones.

Second, teams can split the work: For example, one person working on the new single-site strings, while another person is working on wordpress-ms.pot.

[nacin]

I wonder if it makes sense to load MS strings on WP_ALLOW_MULTISITE? Seems like that constant may end up defined as true in some cases to expose Tools > Network even if they decide not to trigger it. Some one-click/easy install services or providers may even include it by default (assuming they support multisite of course).

I understand that is probably a rabbit hole because on network.php, we may need strings deeper in MS, but maybe if we're not multisite but we are on network.php's step 2, we can load the MS strings manually.

[nbachiyski]

(In [15064]) Better detection whether we are on the Network page. Use custom constant to tell us. See #13565, props nacin

We used to load multisite translations each time WP_ALLOW_MULTISITE was defined, but
it could lead to alot of false positives. Generic config files can include to allow
users to updgrade to multisite without further editing the config file.