Localised installs no longer receiving translations for bundled themes

[dd32]

As part of [17576] (#14484) updating of bundled themes was removed from the core update process. The bundled theme updates process was left to the standard theme updater.

As a result of this, Translated builds no longer receive updated translation files (as the .org version of the theme does not contain any translation files).

This was a known issue for 3.2, however, Language packs were to take over for 3.3, and that hasn't happened.

Note: Previous to the above changes, If a user updated their bundled theme after updating core, they'd lose translation files too.

We need to include some way for localised builds to receive bundled theme translations, either:

1. Actually include translation files with the theme (which is what every other theme would be doing) - Language Packs will remove the need for that
2. Include twentyeleven/twentyten language files in wp-content/languages/ - but I don't believe the load_textdomain() call will load from there?
3. Forcibly copy wp-content/themes/twenty(ten|eleven)/languages/ over during the update process when wp-content/themes/twenty(ten|eleven) exists - This will still result in translation loss when a user updates their theme after core.

3 is a band aid until language packs eventuate, and seemingly the best option if 2 isn't possible. 1 has downsides over all copies ending up with a tonne of extra language files which may or may not be used.

See: ​http://wppolyglots.wordpress.com/2011/10/15/hello-translation-for-twenty-eleven-isnt-included-in/ and ​http://wppolyglots.wordpress.com/2011/07/13/twenty-eleven-losses-translation-after-3-2-1-update/

[scribu]

Include twentyeleven/twentyten language files in wp-content/languages/ - but I don't believe the load_textdomain() call will load from there?

Yes, it will, and I think this is the method we should adopt; it paves the way for language packs.

[scribu]

Clarification: load_textdomain() will load any path.

load_theme_textdomain() is the one that's hardcoded to the current theme directory and should probably be modified to check in languages/themes/ as well.

[dd32]

Yeah, that's what I meant, the current call in the Twenty* themes won't load from the languages folder currently from what I understand.

Adding the first part of language packs by checking the languages folder as well would be a good method, both as reducing duplicated efforts and removing the need for bandaids.

Language Pack GSoC project SVN: ​http://gsoc.svn.wordpress.org/2011/Osho34/ and Language Packs: #18200

[scribu]

18960.diff​ looks for a .mo file in languages/themes/twentyeleven/ and uses $path only as a fallback.

This has the advantage that all themes will be language-pack ready out of the box.

[nacin]

I've got no objections to 18960.diff, and it's what I had planned for language packs.

For 3.3 I do plan for partial and specialized builds to be ready for localized versions. That means that we can package the proper language files in the initial builds, AND keep the mo/po files updated in /languages/ for upgrades. That's a sensible approach that can then be phased out later.

[dd32]

Better standardise on the directory structure now then.

The patch uses WP_LANG_DIR/themes/$domain/$locale.mo

Including the themes directory is useful to separate translations, but prevents a generic "Load this text domain now" ability without checking root, themes, and plugins directories in the future.
Given the textdomain needs to be unique across the install, and there'll be a management interface for it later, it might be worthwhile skipping /themes/

[scribu]

The patch uses WP_LANG_DIR/themes/$domain/$locale.mo

That is incorrect; the patch uses WP_LANG_DIR/themes/$theme_slug/$locale.mo

The textdomain does need to be unique, but not the filenames. So you could have both a plugin and a theme with different textdomains, but with the same slug.

Something else I was thinking about was that it might be good to include the theme slug in the file's name, rather than having separate directories, so that it's always clear which theme you're handling. That's how it works for plugins.

So, the path would look like this:

WP_LANG_DIR/themes/$theme_slug-$locale.mo

[dd32]

That is incorrect; the patch uses WP_LANG_DIR/themes/$theme_slug/$locale.mo

Ah, my mistake, I got lost between reading the patch and commenting (.org themes text domain must match the theme slug I believe).

In this case, I think we should ignore the theme slug all together, We're dealing with storing translations for a text domain, not storing translations for a theme specifically, it shouldn't matter what theme it's for, the only important information is the text domain, and the path that that file should be found in.

[scribu]

Ok, then I guess for both plugins and themes, the choice boils down to either:

WP_LANG_DIR/$domain/$locale.mo

or

WP_LANG_DIR/$domain-$locale.mo

[dd32]

We need to decide on a "standard" for the language directories here..

[scribu]

Well, unlike previously, a WP installation would only contain the language packs it needs, so if we were to go with WP_LANG_DIR/$domain/$locale.mo, most of the time each directory would only contain two files, which would be annoying.

So, I'm for WP_LANG_DIR/$domain-$locale.mo.

[dd32]

So, I'm for WP_LANG_DIR/$domain-$locale.mo.

That's got my vote too

• For most users of a single language, it'll just be a list of files for each domain, simple structure and to the point
• For users with multiple locale's installed, It'll at least be grouped by domain

[nacin]

WP_LANG_DIR/themes/$domain-$locale.mo and WP_LANG_DIR/plugins/$domain-$locale.mo would be better, and that was the plan for language packs. On WP.org/extend at least, the slugs are only unique in their individual namespace.

[dd32]

the slugs are only unique in their individual namespace.

My thinking was that since the text domains are "unique", they're pointless being separated like that (since gettext can only load one translation set).. however, I assume if multiple textdomains were loaded, it'd simply merge them together.. which does indeed require plugins and themes to have seperate storage since they could clash.

Sounds like the patch here is the go then.

[scribu]

18960.2.diff​ uses WP_LANG_DIR . "/themes/$domain-$locale.mo" as discussed.

[azaozz]

No traction in 4 weeks, are we doing this so late in the release cycle or leaving for 3.4?

[dd32]

I think we can safely drop this in for 3.3, however, that's depending on it actually being used by the build process (which it isn't currently). As it is, users with non-english installs using twentyten/twentyeleven have to manually install translation files after each release when we bump the theme versions.

[dd32]

In 22346:

Theme Translations: Allow for theme pomo files to be loaded from WP_LANG_DIR/themes/{$domain}-{$locale}.(p|m)o.
This directory format is what we have chosen for Language Packs (See #18200), but which is currently delayed.

By making this change, we can ship localised theme files within core for bundled themes, and avoid the issues associated with Theme Updates overwriting/removing the language files.

Fixes #18960

[nacin]

I've deployed changes to wordpress.org's localized package builder to place bundled theme po/mo files in the new location starting in 3.5. Tested and good to go.

Here's what the build looks like: ​http://nl.wordpress.org/builds/nl_NL/trunk/wordpress-3.5-beta2-22352-nl_NL.zip.