Internationalization goals for WordPress 4.0

Internationalization goals for WordPress 4.0

Hello all. Earlier today I published a post on make/core called Internationalization goals for WordPress 4.0. This of course affects you so I wanted to make sure you saw it and give you the opportunity to provide feedback. I am sure you will have questions as to how this will affect translation teams, which you can ask here if you’d like.

Let me outline the goals for WordPress 4.0. I’ll then answer what I anticipate will be some frequently asked questions.

  1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.
  2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.
  3. You should be able to search from the dashboard for plugins and themes that are available in your language.
  4. All localized packages should be able to be automatically generated and made available immediately as part of the core release process.
  5. Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

Does this mean I will no longer need to create builds and releases?
That’s the idea. If at time of core release you are 100% translated, then I’d want everything to be packaged up automatically. Ideally, the Rosetta builder will go away entirely.

The builder will go away? But what about alpha/beta/RC releases?
We’ll make it possible to build these.

What if my locale doesn’t make any modifications?
Once this goes into effect, you won’t be able to make local modifications anymore. The whole process is being simplified. We’ll be retiring the ability to ship a {$locale}.php file or to add files to dist/. Future adjustments will need to go through WordPress core.

What if my locale currently requires local modifications?
We’re not going to make the experience worse for your users by preventing you from making these modifications. As I noted in the post, about 14 locales make changes that WordPress core will need to account for first, not including readmes, licenses, and the sample config file. This is going to be similar to my efforts in 3.4 to reduce the number of hacks you needed to make. Once your locale no longer requires modifications, legacy modification support will be disabled for your locale.

So, how are we going to translate readmes, licenses, and sample config files?
I don’t know yet. They will either continue to be done in SVN, incorporated into the Rosetta dashboard, or somehow imported into translate.wordpress.org. You won’t need to update the readme with each version, though; we’ll be sure of that.

Does this mean SVN won’t be needed anymore?
The idea is to simplify the entire process down to translation. You shouldn’t need to be a developer, or know how to use version control, or be awake to immediately push a build, or be responsible for issues like this.

What if I want to use SVN still?
I plan to drop support for building packages directly from SVN. This isn’t just simplifying the process. It will also drastically simplify the complex build system behind Rosetta (yes, the rest of it will be open-sourced) and improve maintainability. If you’re one of the three or so translation teams that make liberal use of SVN, I imagine we can work something out. (After all, GlotPress makes it easy to import PO/MO files.)

Will this eliminate the double-upgrade annoyances?
You bet. There will no longer be irrelevant “in English” warnings. Automatic background updates will “just work” without leaving you confused.

Do language packs mean I can fix a typo post-release?
Yes! Language packs for core WordPress releases will mean that updating the strings will be separated from updating the software itself. We don’t typically change strings in a point release because it slows you down in shipping a package (which is sometimes a security fix), but we might do that in the future with enough warning. And if you have a typo in a translated string, you could fix it whenever, and the language pack would simply be rebuilt and re-served to installs — no need to wait (or hope) for a point release.

This post mentions plugins and themes, but when is all of that coming?
Basic language pack support is live for a few select plugins (bbPress, BuddyPress, Akismet) and I expect to have a wider pilot program ready in the coming weeks. More details to follow, promise.

Nacin, you forgot about X!
The post and its comments mention a few things that aren’t going to happen for 4.0, like “Admin in English,” per-user languages, per-post languages. (We need to walk before we can run.) If something is missing that should probably be in 4.0, please mention it. Or if I over-simplified something in that post (as in, it doesn’t look like I accounted for how complex something is going to be to do), please enlighten me.

Bonus: How can I help build all of this?
Great question! I’ll be shifting tasks into tickets on both core and meta Tracs in the coming days. If there is something in particular you want to help with, please let me know.

#4-0, #announcement, #core