WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 6 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 7 years ago.

Download all attachments as: .zip

Change History (18)

#1 @dd32
7 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
6 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
6 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
6 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
6 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
6 years ago

Related: #13230

#7 @zeo
6 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
6 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
6 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
6 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
6 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
6 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
6 years ago

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

#15 @ryan
6 years ago

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

#16 @ryan
6 years ago

Default theme updated to use i18n version.

#17 @westi
6 years ago

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

Thanks.

Closing as fixed.

Note: See TracTickets for help on using tickets.