WordPress 3.4 will be released within the hour. Start your engines.

This is where GlotPress keeps weirding me out: http://cl.ly/0520243U2f0Q021B2006 Every single view shows there a no strings left to translate, but yet it keeps nagging me about 5 untranslated strings. Is this a cache issue or a bug @nacin?

I am using Poedit for testing localization and there are 1664 strings in my .po file (updated from wordpress.pot), but in GlotPress there are 1689 strings. In admin and network admin files is everything OK. Strange…

Browse Happy shows no “Like” button for Safari, on Safari (I know…). Can anyone else reproduce this self-loathing?

Hello, I’m the former maintainer of WordPress Uighur Forum. I haven’t look after it for a long time, and today I found that this forum filled out by spam posts. I can’t delete these posts so please delete all posts in http://ug.forums.wordpress.org/. It would be very nice to change it as a plugin, I think.
Thank you.

Hi folks, first time here, nice to meet you!

This post is for poly-developers:

Nowadays, it doesn’t bug me because I submit translations to plugin authors. But in the old days, I lost some translations due to some update.

I don’t know if this been discussed before by this community or if there are rules already established.

The case is that this looks like the definitive solution:
http://www.geertdedeckere.be/article/loading-wordpress-language-files-the-right-way

And I think the matter hasn’t been settled yet, as we have this as a proposed idea:
http://wordpress.org/extend/ideas/topic/a-wat-to-preserve-language-files-when-updating-themes-and-plugins

salut a tots!

Browse Happy!

Hello everyone — WordPress runs a site called Browse Happy, which you’ve probably seen, at http://browsehappy.com/. Here’s a bit about it:

Using an outdated browser makes your computer unsafe. Browse Happy is a way for you to find out what are the latest versions of the major browsers around. You can also learn about alternative browsers that may fit you even better than the one you are currently using.

The theme is fully internationalized and I would like to offer it in as many languages as possible.

Like WordPress.org does when directing you to a locale site, Browse Happy will be able to detect your browser’s preferred language and then offer you the ability to view the site in that other language. We will also do either a subdomain or a path to allow direct-linking to a local site (so de.browsehappy.com or browsehappy.com/de/).

You will then be able to link to the localized version in core. Browse Happy is only 29 strings, so I hope to launch with a few languages next week!

Here is the project on translate.wordpress.org. Let me know if you have any questions. Happy translating!

@nacin, Currently, “Copy from original” isn’t working with strings that have plural form. Also, if I reject a suggestion for some string, it won’t be displayed in the untranslated list after that. In order to translate it, you have to do an export or filter by rejected strings.

@nacin, in http://core.trac.wordpress.org/browser/trunk/wp-includes/class-wp-customize.php#L640, I see a

<label>%s %s</label>

string for translation, but can’t figure out why a) the html tags are in there (some people *will* translate them and break it) and b) the two %s. Either a comment is needed or that line is wrong.

Some problem here.

When you go to catalan webpage you get a blank page:

Home

Do you know what’s the problem?

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? 🙂

I noticed today that upgrading TwentyTen and TwentyEleven to their 1.3 version make said themes loose their translations if they previously had some. Any idea who to talk to about this and / or where. Perhaps you know @nacin ?

Is there a way, other than asking here, to update the po/mo on the nl.wordpress.org site to the latest 3.3 version? I want to make a new screenshot but it looks rather silly with New in the toolbar instead of Nieuw 😉

We’re in string freeze.

Heads up on timing: We’re aiming to release 3.3 final before December 13.

Please post here and use the “core” tag if there are any issues, typos, etc. If we need to change a string, I will post here (and beg for forgiveness). Tickets with potential string changes will be marked with the ‘i18n-change’ keyword.

Validators are now controlled through Rosetta

Editors of Rosetta sites can now control who the validators are for their language. GlotPress will use these permissions across all projects on translate.wordpress.org. You no longer need to post validator requests here.

Validators are users of that locale’s Rosetta site having the role of Editor, Author, or Contributor. You can also use the new role of Validator (otherwise equivalent to Subscriber). I’ve ported over all existing validators.

Editors can now add and promote users, as well as edit the theme’s screenshots and navigation menu (Themes > Custom Header and Menus, see previous post). All administrators are now editors instead.

With this change, we’re also dropping support for locales that do not have a Rosetta site. This applies to 21 languages*, all of which are inactive anyway. GlotPress will no longer function properly for these languages, and a future cleanup will likely remove them from SVN and elsewhere.

(* – Affected languages are: br, gd, kk, ku, lt, mn, no, pa_IN, zh, az, bn_BD, en_GB, es_CO, fo, haw_US, is_IS, kn, ky_KY, lb_LU, ta_IN, ur.)