WordPress.org

Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#12425 closed enhancement (fixed)

Fallback theme code is not translatable / default theme in theme repo is not translatable

Reported by: Denis-de-Bernardy Owned by: westi
Milestone: 3.0 Priority: high
Severity: major Version: 3.0
Component: General Keywords: needs-patch
Focuses: Cc:

Description (last modified by westi)

Should we switch them both to the I18N version of kubrick/default

Attachments (1)

12425.diff (472 bytes) - added by Denis-de-Bernardy 11 years ago.

Download all attachments as: .zip

Change History (18)

#1 @dd32
11 years ago

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

(In [13500]) Allow WP_FALLBACK_THEME to be overridden. Props Denis-de-Bernardy. Fixes #12425

#2 @Denis-de-Bernardy
11 years ago

  • Keywords needs-patch 2nd-opinion added; has-patch commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

re-opening, because I'm foreseeing a possibly trickier issue.

consider a user with the simplest theme possible. two files, index.php and style.css, that currently relies on get_header(), get_sidebar() and get_footer(). that user is currently relying on the default theme. making him use twentyten all of the sudden makes no sense.

in other words, we should: during the upgrade, add an option with a value of default; and during installs, add an option with a value of twentyten. and then use the option to set the define.

alternatively, we could tell these handful of users (there can't be that many) to add the appropriate define in their wp-config.php file. in this case, the existing fix works wonders.

#3 @technosailor
11 years ago

In an upgrade, unless the user explicityl removes the default (Kubrick) theme, it will still be there. In a 3.0 install, they would get twentyten. I don't see this being any more of an edge case and suggest we close as invalid.

#4 @westi
11 years ago

  • Keywords 2nd-opinion removed
  • Owner set to westi
  • Status changed from reopened to accepted

Working on a solution to this as well as #13009

#5 @westi
11 years ago

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

(In [14365]) First pass of compatibility code for old themes which relied on using templates from the default theme without expressly identifying it as the parent theme.
Fixes #12425 and #13009.
The fallback to these template files is now depreceated and will be removed in a future version.

#6 @scribu
11 years ago

Related: #13230

#7 @zeo
11 years ago

westi, does theme-compat need to be localized or leave it as is? If yes, what's the domain for it? none?

#8 @nacin
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I think we can use the i18n version, in the kubrick/default textdomain. If it's not loaded, then we get English, that's fine too. If it doesn't exist, the theme wouldn't work anyway.

That said, wondering if we can just fall back to kubrick, and forgo theme-compat. If it doesn't exist, the theme wouldn't work anyway.

#10 @westi
11 years ago

I went for untranslated to hi-light it more as being a dead-end.

Also I copied the files from the WordPress Extend version of the default theme so if we are going to use the I18N one we should update that as well as otherwise when people apply the suggested fix to there theme they will lose the translation goodness.

#11 @zeo
11 years ago

Is there anyone still using comments-popup.php?

How about just copy from i18n repos to extend theme repos. But the Default theme in Extend is out of reach. How to submit patches? Themes trac seems dead anyway.

#12 @westi
11 years ago

  • Description modified (diff)
  • Priority changed from normal to high
  • Severity changed from normal to major
  • Summary changed from allow to override the fallback theme to Fallback theme code is not translatable / default theme in theme repo is not translatable

Retitling to reflect current issues.

Raising Priority.

#13 @nacin
11 years ago

I would opt for this:

  1. Replace current Kubrick files in the wp.org repo with the i18n version.
  1. Remove theme-compat, and hard-code a search for /default, and deprecate this behavior.

This prevents us from adding new strings to core or requiring a separate pot file or translations for theme-compat.

If it is a fresh 3.0 install without default and without theme-compat, and they try to use a theme using the deprecated behavior, then that's their problem. It is also very easily fixable, by downloading Kubrick, and, to eliminate the deprecated behavior, adding "Template: default" to the style.css.

I think theme-compat was a good idea but it introduced an oddity/complexity when it comes to translations (and modified Kubricks, for that matter), and thus breaks more than it needs to.

#14 @westi
11 years ago

(In [14771]) First pass of conversion of theme-compat to the I18N version of the files. See #12425

#15 @ryan
11 years ago

Updating "default" in the theme repo is in progress.

#16 @ryan
11 years ago

Default theme updated to use i18n version.

#17 @westi
11 years ago

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

Thanks.

Closing as fixed.

Note: See TracTickets for help on using tickets.