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

[Denis-de-Bernardy]

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

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

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.

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.

Working on a solution to this as well as #13009

(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.

Related: #13230

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

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.

see kubrick/default:  http://svn.automattic.com/wordpress-i18n/theme/trunk/

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.

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.

Retitling to reflect current issues.

Raising Priority.

I would opt for this:

1. Replace current Kubrick files in the wp.org repo with the i18n version.

2. 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.

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

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

Default theme updated to use i18n version.

Thanks.

Closing as fixed.