I added persistent caching to translate.wordpress.org, fixed a bug in GlotPress, and tweaked a few things. The result: GlotPress is now super fast. Even the really slow project pages now load in an instant. See for yourself: http://translate.wordpress.org/projects/wp/dev. Let me know if you see anything funky, such as stuck values (caching issues) etc.
Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts
I think we are going to turn off the SVN builder for 3.4.
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.
Request for feedback from East Asian languages for WordPress 3.4 core modifications.
In #8759, I’m looking for feedback for the editor word counts.
In #16079, I’m looking for feedback for the length of auto-generated excerpts.
If you could test the code and post in the relevant tickets, it would be much appreciated.
Need some RTL feedback here: http://core.trac.wordpress.org/ticket/6425. How should be be handling RTL content in RSS feeds?
I’ve updated the list of 3.4 changes:
- New: Localizing commas, as a tag separator
- New: Fields that should always be LTR
- New: Spellchecker language is now translatable
- Changed: How precisely core detects that a language is RTL (it now uses a translated string)
3.4 update: Localizing quotes and apostrophes that go through wptexturize(). More
In 3.4, you no longer need any PHP to customize the defaults for start of week, feed language, or default timezone. (You would have hooked into populate_options for these.)
start_of_week and timezone_string/gmt_offset are now translatable, and rss_language is gone (it uses the site’s locale, now).
I’ve created a page here that outlines all changes to 3.4 so far, including the details for how to set these defaults: Important Changes for WordPress 3.4. I will update it as more changes happen.
For 3.4, the default links are now translatable, both titles and URLs. http://core.trac.wordpress.org/changeset/19781
I left out the URLs for extend/plugins/, themes/, and ideas/ from being translated as there are not yet official localized resources for these, and I would not want to send them off-site. Since the forums are a better conduit for feedback anyway, I demoted Suggest Ideas down the list, moving the Support Forums up one.
In GlotPress, you may need to export 3.3.x/ms strings and import them into dev.
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.
In 3.4, you will no longer need to specify a $wp_default_secret_key, in $locale.php or in default-constants.php. For many of you, this means your $locale.php file will now be empty. Branch off 3.3 and remove $locale.php from /trunk/dist/ if that is the case. See ticket 19599 for more.
All locales: In 3.4, you will no longer need to override wp-admin/setup-config.php. The strings in this file will now be included in the POT, and the config file will be generated properly regardless of the wp-config-sample.php placeholders such as “your_username_here”. See  and #18180.
RTL locales: In 3.4, you will no longer need to specify
$text_direction = 'rtl';in your $locale.php file. Please remove it from $locale.php, and if this makes your $locale.php empty, then remove the file. (Please branch /trunk/ off into /3.3/ first, in case there is a 3.3.2.)
The following locales have been included: ar, ckb, fa_IR, he_IL, ug_CN, dv, fa_AF, ha, ps, uz_UZ, yi. If you are missing (or are incorrectly included), let me know.
The release of 3.3.1 is imminent. It is a security and maintenance release. There are no new strings. Please deploy promptly. Thanks!
Moving Locale-Specific Modifications into Core
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?
“Translate from Google” — Did it get any use by you guys? Did not having it slow you down? Did not having it improve quality? Would anyone like it back?
Hello everyone I’ve made some changes and I… « GlotPress, Torsten, Rami, and 13 others are discussing. Toggle Comments