Here’s where we are on the five goals for internationalization outlined previously:

1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.

First pass done in #28577. There is a list of things to do in the ticket, which includes:

  • Improved error handling when the API or filesystem isn’t accessible. Working on this.
  • Bring this to setup-config.php. Working on this.
  • Place browser-based language suggestions at the top. Working on this.
  • Use better markup rather than simple select/option HTML, currently being worked on by @jorbin.

2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.

This simply requires replacing mu_dropdown_languages() with a new method that handles uninstalled languages gracefully. This is easy to implement and relies on much of the same code as the install process, so it’s simply on hold until that’s done. I’ve also worked out a UX flow with @sonjanyc.

3. You should be able to search from the dashboard for plugins and themes that are available in your language.

This is handled on the WordPress.org side. The updated plugins screen will need to pass a new argument to filter by language, and then remove that argument if the user requests showing plugins in any language. We’ll need to hack in readme/description translation support but that’s a small API change and otherwise WordPress.org work, not core work.

4. All localized packages should be able to be automatically generated and made available immediately as part of the core release process.

A script for this is written. While it needs more work, it was used as a test to build 3.9.1 packages, which are doubling as 4.0-alpha testing packages. This does not require changes in core.

5. Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

This is ready. A flag needs to simply be flipped in the API.

Ongoing problems to solve:

  • I have a proposal to type up for how to handle readmes, license files, etc., in both core and plugins. Requires no core changes.
  • No one has picked up the plan to limit the code modifications still done in some locales. This may end up being a July project for me.
  • The relevant APIs we need in core were deployed to WordPress.org. Also, the plugin and theme directories are fully internationalized; we need to get those strings to translators and shoehorn them onto existing international sites.