Make WordPress Core

Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#18960 closed defect (bug) (fixed)

Localised installs no longer receiving translations for bundled themes

Reported by: dd32's profile dd32 Owned by: dd32's profile dd32
Milestone: 3.5 Priority: normal
Severity: blocker Version: 3.2
Component: Upgrade/Install Keywords: has-patch commit
Focuses: Cc:


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: and

Attachments (3)

18960.diff (1.3 KB) - added by scribu 13 years ago.
18960.2.diff (1.3 KB) - added by scribu 13 years ago.
18960.3.diff (1.3 KB) - added by dd32 12 years ago.

Download all attachments as: .zip

Change History (27)

#1 @scribu
13 years ago

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.

#2 @scribu
13 years ago

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.

#3 @dd32
13 years ago

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: and Language Packs: #18200

#4 @scribu
13 years ago

  • Keywords needs-patch added; 2nd-opinion removed

#5 @knutsp
13 years ago

  • Cc knut@… added

13 years ago

#6 @scribu
13 years ago

  • Keywords has-patch added; needs-patch removed

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.

#7 @nacin
13 years ago

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.

#8 @dd32
13 years ago

Better standardise on the directory structure now then.

The patch uses WP_LANG_DIR/themes/$domain/$

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/

#9 @scribu
13 years ago

The patch uses WP_LANG_DIR/themes/$domain/$

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

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:


Last edited 13 years ago by scribu (previous) (diff)

#10 @dd32
13 years ago

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

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.

#11 @scribu
13 years ago

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




#12 @dd32
13 years ago

  • Keywords dev-feedback added

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

#13 @scribu
13 years ago

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/$, most of the time each directory would only contain two files, which would be annoying.

So, I'm for WP_LANG_DIR/$domain-$

#14 @dd32
13 years ago

So, I'm for WP_LANG_DIR/$domain-$

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

#15 @nacin
13 years ago

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

#16 @dd32
13 years ago

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.

#17 @scribu
13 years ago

  • Keywords commit added; dev-feedback removed

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

13 years ago

#18 @aesqe
13 years ago

  • Cc aesqe@… added

#19 @azaozz
13 years ago

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

#20 @ryan
13 years ago

  • Milestone changed from 3.3 to Future Release

#21 @dd32
13 years ago

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.

12 years ago

#22 @dd32
12 years ago

  • Milestone changed from Future Release to 3.5
  • Owner set to dd32
  • Status changed from new to accepted

#23 @dd32
12 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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

#24 @nacin
12 years ago

I've deployed changes to'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:

Note: See TracTickets for help on using tickets.