Language Packs

[nacin]

Implement language packs for core, plugins, and themes.

Inspiration and code can hopefully be derived from the corresponding GSoC project.

This will require quite a bit of work in GlotPress, on api.wordpress.org, and in core. I will take point, but assistance will be needed. A number of decisions will need to be made. I will begin designing a document for what exactly needs to be done over the next week.

Two files are currently hard-coded and committed into SVN by translators: setup-config.php, and wp-config-sample.php.

18200.diff​ implements WP_I18N in setup-config.php. It does not yet touch the default constant values, which must match wp-config-sample.php (and code exists on WP.org to verify this).

The goal would be for these strings to be implemented directly into GlotPress and for wp-config-sample.php to then be filled out in Rosetta. (Rosetta is the code and associated tools that power the local language sites, such as ​http://pt.wordpress.org/.) This will then remove the SVN requirement for nearly all core packages. (I haven't gotten into $locale.php or special plugins yet, but we will.)

A sanity check on my syntax for this patch would be appreciated. Untested and I may have missed a string.

Replying to nacin:

Two files are currently hard-coded and committed into SVN by translators: setup-config.php, and wp-config-sample.php.

There's also:

• readme.html
• $wp_default_secret_key in default-constants.php (not required, but prevents the admin area from breaking after installing some plugins, see #14024 and the ​post on WP Polyglots)

Replying to nacin:

A sanity check on my syntax for this patch would be appreciated.

Tested installation, works fine. Minor correction in line 85:

'WordPress › Setup Configuration File'/*WP_I18N_SETUP_CONFIG_EXISTS*/;

Should be:

'WordPress › Setup Configuration File'/*/WP_I18N_SETUP_TITLE*/;

Re-opened #18180 and will continue setup-config.php conversation there.

Related: #16775

Related: #15977

It was decided at last week's dev chat to punt this because we are past freeze and it's not quite done. Hopefully it will be ready as soon as we open the 3.4 branch.

Related: #18960

Related: #19832

refresh of last alterations

Oh, dd32, why you didn't post a comment, we could have never seen this patch? :)

Anyway, I'll try to summarize what this patch does so you correct me where I'm wrong:

• On core/plugins/themes check for updates, we now check for languages too.
• Checks for languages are done by searching for language files in WP_LANG_DIR, from which is then PO-Revision-Date taken to be sent to api.wp.org.
• When any install/upgrade of core/plugin/theme is done, rechecks for updates are forced for everything so that there are fresh results against latest versions.
• After that, upgrades for available languages updates for everything (core/plugins/themes) are forced.

Oh, dd32, why you didn't post a comment, we could have never seen this patch? :)

Because the patch is more than useless without the WordPress.org infrastructure being setup (And it wasn't set up, and still isn't ready). Those that needed to know there's a patch here knew about it :)

The overview of what you've said sounds about right for the process it'd be doing.

Considering this for 3.5 for bundled themes and importers.

Refreshed patch - completely untested

Do we have the WordPress.org infrastructure now?

Language Packs are currently blocked by needing WordPress.org development, Shifting out of 3.5 since it won't be included.

In 22346:

Theme Translations: Allow for theme pomo files to be loaded from WP_LANG_DIR/themes/{$domain}-{$locale}.(p|m)o.
This directory format is what we have chosen for Language Packs (See #18200), but which is currently delayed.

By making this change, we can ship localised theme files within core for bundled themes, and avoid the issues associated with Theme Updates overwriting/removing the language files.

Fixes #18960

Attached patch implements changes from [22346] to plugins.

Non-blocking

I disagree that this needs to wait WordPress.org infrastructure before inclusion in core. The way this should work based on proposed patch is that when there is no WordPress.org infrastructure it won’t return anything language related so it would simply work as before.

This means that infrastructure might get ready late in release cycle, or even after release, and in that time we’ll have core side done and tested. Core support doesn’t require API (api.wordpress.org) support, it’s only required if you want to have it as an official feature.

Probably, in beginning there will be need for some change in API’s response so that response can be able to hold information for a few language-core/plugin/theme combinations that would have pre-made static language packages for testing purposes. This shouldn’t require too much changes.

Testing

I tested patch by @dd32. Everything in install/upgrade of core/plugins/themes worked as usual so there is nothing breaking. For packs, even if response had language information, nothing would happen since patch doesn’t save that data.

So I modified it (see attached patch) with presumption that structure of API responses is same. Response for core is already structured so that there are a couple of keys with different content and it would simply access one more for languages. Plugins and themes responses offer arrays where first level keys are names of plugins/themes so it just checks for language_updates key and unsets it.

Then I forced response to hold language information with pre-made packages (see attached plugin).

With language_updates available, upgrader would download and extract language files as expected.

Improvements

There are possible improvements to this core workflow:

• API responses for plugins/themes should change to be in line with core one (current array of updates can be under offers key, with languages under language_updates).
• API requests should have one more key along installed_languages that carries language codes so that site can get language files even if there aren’t installed language files.
• On unistallation of plugin/theme, associate language files should be deleted too.
• Action links on upgrader screen should be maybe shown after language updates are done to avoid possible interruption caused by user’s click on those links.

GlotPress

On GP side, I added some related patches, like introducing hooks when translation is changed (to rebuild package) or projects branching. I have other ideas for GP improvements but that’s blocked by lack of any development over there.

Conclusion

I propose that core support for language packs lands early in 3.6 cycle. This would give enough time for testing and shift attention to WordPress.org and GlotPress since they need a lot more changes.

Refreshed patch, tested as described in comment:ticket:18200:43

Plugin used to test attachment:ticket:18200:lp.5.diff​ as described in comment:ticket:18200:43

In 23912:

WP_Upgrader: Add upgrader_process_complete hooks and add a abort_if_destination_exists flag (default is true). props dd32. see #18200.