Thanks in advance!

Strings for WordPress 3.5 are now frozen.

The targeted release date remains December 5, 2012 (the same date we announced at the start of the cycle).

Unfortunately, this means I’m very late in formally declaring a string freeze. This is entirely on me and I accept responsibility for the delay.

With the exception of the About page, we’ve had only a handful of string changes over the last week. Most translations seem to be in fantastic shape this release, which is a great sight to see. I hope all of you are able to step up and push through.

If you find any typos or other issues, please report them to http://core.trac.wordpress.org/. If you have any questions (or are just plain frustrated with me), feel free to leave a comment.

Note you’ll now be using WordPress.org usernames here. If there are any issues, let me know.

All of your existing subscriptions were transferred over (post or comment subscriptions via email, RSS, or Jabber). We also automatically mapped WP.com usernames to WP.org usernames when transferring the posts.

The GlotPress project has already been preloaded with translations pulled from WordPress.com and previous Jetpack versions. There are 465 strings in this release, and many languages are already above 50%.

There is a slight chance that a couple of strings will change before the release, as 1.3 is still going through the final testing. We’ll post a note here if that happens.

If you would like to have a language added to Jetpack and/or or want to be assigned as a validator for your language (especially if you already validate WordPress translations), please leave a comment and we will help you out.

Thanks in advance for your help!

An important note. One, you can still build from SVN, there is requirement to use GlotPress at this time. Two, I made numerous changes to many locale’s /dist folders — the folder at i18n.svn.wordpress.org where we pull readme.html, wp-config-sample.php, etc. — in preparation for 3.4. You are going to want to use your 3.3 branch or tag for /dist if that is the case. (I made branches for you if they didn’t exist.)

So: Check to make sure you are using the right /dist.

You can check the changelog to your SVN directory here: http://i18n.trac.wordpress.org/log/pt_BR (change pt_BR to your locale folder). And browse yours here: http://i18n.trac.wordpress.org/browser/pt_BR.

And: TEST YOUR BUILDS.

If there are any issues, post here, and I, Zé, and others will do my best to resolve them.

You will still be able to use your SVN directory, and we will continue to pull files from /dist (like readme.html and wp-config-sample.php). But, in order to create a build, you will need to import any po/mo files you have into the wp/dev projects at translate.wordpress.org.

GlotPress is all about collaboration. So others may help, it is preferred that you periodically import your po/mo files there (if you work with a separate tool), rather than importing them at the end in order to do a release. This also isn’t just about collaboration. At some point, I’d like to make it so you can mark your locale as “ready” for a release. Then we will simply create the build for you when we release WordPress.

For 3.4, we’re changing how we split strings into multiple pot files. Since 3.0, we’ve done a generic POT and then a second POT for multisite. We are now going to be doing a frontend POT, an admin POT, and a network admin POT. The projects have been added to GlotPress here and here.

While merging and splitting projects in GlotPress, some strings got orphaned. Before you go re-translate all of the missing strings, first go to translate.wordpress.org/projects/wp/3.3.x/ms, export a po file, and import it into both wp/dev/admin and wp/dev/admin/network. Everything should be back to normal.

Cheers, and sorry for the trouble. For more, see ticket 19852.

The core team is intending to propose for 3.4 that all locale-specific modifications get moved to core. Ideally, this will reduce all (or nearly all) packages to mo files, po files, and readme.html.

What does that mean? All plugins, locale.php files, JS, CSS, etc., will all end up getting a complete review and become part of core. Any future changes will then take place with new versions of WordPress, and will be tracked on core Trac. Translation teams will still advise on, and ideally drive, any needed changes.

I think it’s pretty clear as to why we’d like to go in this direction. This will happen in parallel with language packs. To get there, we will need to simplify the contents of localized packages. The end goal is to make things simpler for the user, but it also can set the stage for future features, and there are added benefits. One, the core developers will be investing time into problems that translation teams face. Two, translation teams will be prevented from solving complex problems on their own.

We know that in some cases, core tickets for certain problems have rotted for some time, forcing hacks, filters, and plugins. We will not only addressing these, but by tackling these issues, we are making a commitment that extends beyond WordPress 3.4 that localized builds are a major player in the ecosystem.

This is a major undertaking, and we will need your help.

I would like to keep discussion here and pure implementation on Trac. However, to demonstrate how serious we are, and how large the scope of this project will be, here is an incomplete list of Trac tickets assigned to the project:

• #8759 — “Word count” should could by characters in some locales.
• #6425 — Support RTL in feeds.
• #19597 — Allow translation of the bundled plugins’ descriptions.
• #19598 — Text inputs for codes or URLs should be LTR.
• #19599 — Localizations should not need to worry about the default secret key.
• #19600 — Core should know which languages are RTL.
• #19601 — Support localized defaults for options, links, dashboard widgets, etc.
• #19602 — Curly quotes from wptexturize() should not be forced on all locale.
• #19603 — Support locale-specific modifications in core (the catch-all ticket).

I am going to need to have discussions with the fa_IR, ug_CN, ru_RU, zh_CN, ja, and eo locales, as you have complex bundled plugins and locale.php files. Some other locales may have particular concerns as well. We should schedule some public chats in #wordpress-polyglots for this, and to I intend to do a town hall style discussion on #wordpress-polyglots in a few weeks.

Dion Hulse (dd32) is the other core developer on this project, and one of our rockstar contributing developers (and Russian maintainer) Sergey Biryukov will be heavily involved as well.

So, any questions or comments?