[Plugin: Codestyling Localization] Theme is not recognized

The Theme is not working the way Themes should load textdomains. So translation will be loaded unexpected and that’s why not recognized by CodeStyling Localization.
Here are the load steps out of the Themes code:

/* Load theme textdomain. */
		$domain = hybrid_get_textdomain();
		$locale = get_locale();
		load_textdomain( $domain, locate_template( array( "languages/{$domain}-{$locale}.mo", "{$domain}-{$locale}.mo" ) ) );

Each analysis run of Themes expect one of following load methods:

1. load_theme_textdomain
2. load_child_theme_textdomain

But hybrid is using the generic load method: load_textdomain.
So CodeStyling Localization doesn’t recognize it as translatable.

I could support this, but on the other hand side, why the core is able to differenciate loads (core, plugins, themes and child themes) and the Author isn’t using this? I’m not sure to permit generic loads at themes because respect special filters running during load which can’t be intercepted specific anymore by other Authors (plugin as example).

The way the Theme loads textdomains is more like a plugin would do. Domain part for Themes is not supported by my Plugin in any case even if I would make it possible to detect the Theme. So the language file would always (as common for Themes) assumed as example: de_DE.mo and not hybrid-de_DE.mo
So I’m sorry that this Theme won’t be detected but currently I can’t make it work. This could be subject of next major version 2.x still in progress beside support of 1.x versions.

The problem is that translations must be added to the parent theme, Hybrid, when using load_theme_textdomain() because it uses get_template_directory(). This is great until a user updates the parent theme and loses their translation. Hybrid fixes this problem. The method used in Hybrid allows users to add the translation of the parent theme to their child theme instead. That way, the user doesn’t lose the translation upon upgrade.

However, the next version of the theme will call the theme_locale filter hook since it doesn’t get called with load_textdomain(), which was an oversight.

If you want a clean solution with load_theme_textdomain you can hook into the filter load_textdomain_mofile and eval your mo file in real time. Can be found also at load_textdomain and allows to modify the file name (and location to load).

$mofile = apply_filters( 'load_textdomain_mofile', $mofile, $domain );

Because load_theme_textdomain calls load_textdomain at the end, you could easily find your textdomain as “hybrid” and check where to load the file from.

In my opinion there is no real need to bypass the intended way to load language files.

Of course, that’s a cleaner solution. Don’t know why I didn’t think of that in the first place. Updated:
https://svn.locallylost.com/themes/hybrid/trunk

Great, thank you for explanation and solution!

Hmm, strange, I tried latest revision (285) and Hybrid theme is still unrecognized by this plugin?

May be for 2 reasons remaining:

1st) my plugin may have a problem of traversing subfolders as WordPress itself has by Core. So this is eighter fixed wit next WP version or with my next update, sorry for that.

2nd) Even if my plugin would detect the theme and you would created/tranlate it, the patch done will prevent loading this file.
Textdomains for Themes are defined as only locale inside name but Justin prepends the textdomain at least. So this is outside standard and my plugin will create like standard for themes as example “de_DE.mo” but Justin expects for loading “hybrid-de_DE.mo”. I can’t solve this, because this is non standard naming convertion for normal theme load methods!

For #2, you could actually overwrite this just as I’ve done in the theme update with the load_textdomain_mofile hook or apply the hook over the value that you’re pulling (not sure how it’s done in your plugin). Just use a later priority. The reason for the change in the theme is so that the two could play well together while fixing an obvious problem in the way WP handles parent theme translations.

There’s no way for the plugin to know what a plugin/theme might change this to beforehand because of the available filter hook. Even if it’s a non-default string, the plugin needs to account for the possibility that it’d be different.

Non-standard is probably the wrong terminology because WordPress *does* allow this to be changed (as you pointed out earlier) by filtering load_textdomain_mofile. This is a standard WordPress hook, and the theme has been updated to use it. If there’s a better solution on the theme side of things, I’ll be glad to update the code to handle it.

My Problem is, that it scans source files on disk an try to find it out of it. This is a huge text analysis because themes/plugins need not to be activated to deal with this. So I need a ways to be sure about standards of utilization of files to be generated.

Even if this could be hooked the standards is:

function load_theme_textdomain( $domain, $path = false ) {
	$locale = apply_filters( 'theme_locale', get_locale(), $domain );

	$path = ( empty( $path ) ) ? get_template_directory() : $path;

	$mofile = "$path/$locale.mo";
	return load_textdomain($domain, $mofile);
}

This implies, that any language file for Themes (in opposite to Plugins) only consists of “$locale.mo”, in german case “de_DE.mo”
This is what I call standard.

I know your problem by updating parent theme and loosing the user modified translations but your localization would also work as done, if you would use the standards like “de_DE.mo” instead of “hybrid-de_DE.mo” (which is plugin naming).

Nevertheless I’m also working on a proper way how WordPress can fulfill your need out of the box. If it’s working stable, I will put the patch.diff to the trac.

My Problem is, that is scan source files on disk an try to find it out of it. This is a huge text analysis because themes/plugins need not to be activated to deal with this. So I need a ways to be sure about standards of utilization of files to be generated.

That would be problematic. I can’t think of a good solution using that method at the moment but will let you know if I do.

I know your problem by updating Parent and loosing the used modified translations but your localization would also work as done, if you would use the standards like “de_DE.mo” instead of “hybrid-de_DE.mo” (which is plugin naming).

Actually, it won’t work that way. The theme would still need something to differentiate the parent theme translation from the child theme translation because we can’t have two de_DE.mo files in the same child theme directory. That’s the reason for the $domain- prefix.

—

I honestly wish this was handled better in core. Theme translation names should be handled the same as plugin translation names. I might create a Trac ticket to address this if we can’t come up with something.

@pavelevap

Sorry for taking over your entire topic with code talk. I hope we can come up with a great solution for this. We have a great community of translators though, and you might be able to find a translation for your language here:
https://themehybrid.com/themes/hybrid

Nevermind, interesting discussion…

I only wanted to use this plugin to translate Hybrid on the fly on starting website (poEdit is not so good for this purpose – need to upload files after every change). Any solution appreciated in the future, thank you for your answers…

@greenshady
I am working on Czech version which is not available on your website now.

My currently workarround can be used with version 1.99 of my plugin. It detects now also non standard translations for plugins/themes. But it emmits also compatibility warnings for known issues at each listed module affected.

The problem of perfect handling localization (load order / mixing etc.) between parent and child themes is still in investigation phase to find a suitable core fix solution for all possible cases customer/user may have.

Yes, 1.99 recognizes Hybrid theme, thank you very much.

But it is not very usefull for users, because for example cs_CZ.po (and .mo) is created and it is not applied (it needs hybrid- prefix). So, it is not possible to translate online and see results directly on website ?? Is it possible to automatically create required translation file (with hybrid- prefix)?

@pavelevap: The answer is yes and no ??
Indeed I could prepend something, but this would be no general solution. Each theme may do this by its own way so this is more like guessing arround or I had to create (and to support) an extra ordinary list of theme to filename mapping, where I have to register all this exotic themes doing it a way beside the normally intended way.
That’s why my decision was to emmit this warnings with possible work arrounds, sorry if this is not suitable enough for immediate translation checking.
But as long as there is not common defined way to handle all the problems around themes/childthemses, I see no other way dealing with this.
… still working at a comprehensive WP core patch solution.