Twenty Ten i18n - translated strings not visible

[pavelevap]

New ticket for partial problem in http://core.trac.wordpress.org/ticket/14063

There are several strings in .pot file which were translated, but translations not displayed, for example "The 2010 default theme for WordPress." and "the WordPress team".

You can see following discussion here:  http://wppolyglots.wordpress.com/2010/11/27/there-are-some-strings-in-twenty-ten-1-3/

(In [17072]) Handle 'This gallery contains X photos' properly in Twenty Ten. fixes #15858.

[17072] was meant for #15859.

Should we reuse _get_plugin_data_markup_translate() or create a separate function?

Bump. It was problem for Twenty Ten and now it is also problem for Twenty Eleven. Many translators translate long (important and descriptive) strings, but they do not work. Any chance to solve this for 3.2?

Also "Showcase Template" and "Sidebar Template" are not translatable (and not in .pot file). And it is not consistent because "Default Template" is translated in core. So users can see translation of "Default Template" and then not translated template names from Twenty Eleven.

In get_page_templates(), we would possibly run the string through the theme textdomain.

We don't currently have get_theme_data looking for a textdomain header -- I imagine this means we don't support translated headers for themes the way we do for plugins.

These both sound like 3.3 opportunities.

OK, I expected that it is probably too late for 3.2, but this problem is very serious from the point of language packs. Users without English knowledge will not understand for example very informative description about Showcase template and other possibilities of Twenty Eleven.

Related: #19597

15858.diff is the beginnings of a fix for #15858 and #6007. I started by adding TextDomain and DomainPath, then fixed up _get_plugin_data_markup_translate() and added a corresponding function for themes. Page templates were translated.

Then it went downhill. (Or down a rabbit hole, you might say.)

1. get_file_description() is passed an absolute path to a file. Figuring out what theme it belongs to (to ascertain the textdomain) is harder than one might expect.

2. get_themes() should burn in hell and will likely give me night terrors for the rest of the week. Seriously. I struggled with this mess two years ago during GSoC, and returning to it now makes me want to stab my eyes with a pencil.

Other than that, things are peachy.

15858.2.diff isn't an improvement. Decided to take a swing at translating the data of get_themes(). You'd think this would work (given that it is not cached), but haha, you'd be wrong. A few places, mainly the theme editor, rely on $theme_data['Name'] to uniquely identify a theme.

The patch does do something else: It takes the list of tags on themes.php and translates them, which is nice.