Title: [Plugin: Codestyling Localization] Theme is not recognized Last modified: August 19, 2016 --- # [Plugin: Codestyling Localization] Theme is not recognized * [pavelevap](https://wordpress.org/support/users/pavelevap/) * (@pavelevap) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/) * Hi, I tried your great plugin, but [Hybrid theme](http://wordpress.org/extend/themes/hybrid) is not recognized. Codestyling found WordPress and some plugins and themes, but this theme not. I am not sure if it is problem of this plugin or theme? Thank you for your help… * [http://wordpress.org/extend/plugins/codestyling-localization/](http://wordpress.org/extend/plugins/codestyling-localization/) Viewing 14 replies - 1 through 14 (of 14 total) * Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/) * (@codestyling) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618005) * 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. * [Justin Tadlock](https://wordpress.org/support/users/greenshady/) * (@greenshady) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618009) * 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. * Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/) * (@codestyling) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618011) * 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. * [Justin Tadlock](https://wordpress.org/support/users/greenshady/) * (@greenshady) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618017) * Of course, that’s a cleaner solution. Don’t know why I didn’t think of that in the first place. Updated: [http://svn.locallylost.com/themes/hybrid/trunk](http://svn.locallylost.com/themes/hybrid/trunk) * Thread Starter [pavelevap](https://wordpress.org/support/users/pavelevap/) * (@pavelevap) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618104) * Great, thank you for explanation and solution! * Thread Starter [pavelevap](https://wordpress.org/support/users/pavelevap/) * (@pavelevap) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618105) * Hmm, strange, I tried latest revision (285) and Hybrid theme is still unrecognized by this plugin? * Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/) * (@codestyling) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618123) * 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! * [Justin Tadlock](https://wordpress.org/support/users/greenshady/) * (@greenshady) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618124) * 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. * Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/) * (@codestyling) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618125) * 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. * [Justin Tadlock](https://wordpress.org/support/users/greenshady/) * (@greenshady) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618126) * > 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](https://wordpress.org/support/users/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: [http://themehybrid.com/themes/hybrid](http://themehybrid.com/themes/hybrid) * Thread Starter [pavelevap](https://wordpress.org/support/users/pavelevap/) * (@pavelevap) * [15 years, 10 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618127) * 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](https://wordpress.org/support/users/greenshady/) I am working on Czech version which is not available on your website now. * Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/) * (@codestyling) * [15 years, 9 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618133) * 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. * Thread Starter [pavelevap](https://wordpress.org/support/users/pavelevap/) * (@pavelevap) * [15 years, 9 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618134) * 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)? * Plugin Author [codestyling](https://wordpress.org/support/users/codestyling/) * (@codestyling) * [15 years, 9 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618135) * [@pavelevap](https://wordpress.org/support/users/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. Viewing 14 replies - 1 through 14 (of 14 total) The topic ‘[Plugin: Codestyling Localization] Theme is not recognized’ is closed to new replies. * ![](https://s.w.org/plugins/geopattern-icon/codestyling-localization_e6e1e3.svg) * [Codestyling Localization](https://wordpress.org/plugins/codestyling-localization/) * [Frequently Asked Questions](https://wordpress.org/plugins/codestyling-localization/#faq) * [Support Threads](https://wordpress.org/support/plugin/codestyling-localization/) * [Active Topics](https://wordpress.org/support/plugin/codestyling-localization/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/codestyling-localization/unresolved/) * [Reviews](https://wordpress.org/support/plugin/codestyling-localization/reviews/) * 14 replies * 3 participants * Last reply from: [codestyling](https://wordpress.org/support/users/codestyling/) * Last activity: [15 years, 9 months ago](https://wordpress.org/support/topic/plugin-codestyling-localization-theme-is-not-recognized/#post-1618135) * Status: not resolved