Make pomo class flushable/reloadable

[michelwppi]

today, load_theme_textdomain function in functions.php provides way to make theme localizable (but as static way).
Please make this function hookable to avoid coding for no-coding users as explained here - ​http://dev.xiligroup.com/?p=427 - for by instance our xili-language plugin. xili-language plugin provides an automatic selection of language in theme according to the language of one post or rules (category,...). xili-language use and change on the fly the selection of .mo files present in the theme's folder.
With this new filter or action, no need to end users to code...

[hakre]

load_default_textdomain(), load_plugin_textdomain() and load_theme_textdomain() all do not provide a hook. but all use get_locale(). get_locale() has a filter/hook called locale.

Therefore you can use that one. The Feature is already in. Closing as invalid, feel free to add further Feedback and re-open with more information if you seem that fits.

[hakre]

see #9687

[michelwppi]

My purpose concerns only load_theme_textdomain(). Currently set and launched in first lines of functions.php set by theme's designer, it is too early to know which languages must be used for the theme (depending of rules and some results of query). It is why proposed -locale- filter is inapropriate. Dynamic multilingual themes are not exactly running as themes with localization even if - exception of load_theme_textdomain() - xili-language don't change basically anything in theme's coding. By adding a hook (action) that redirects this load_theme_textdomain(), the configuring job of blogger will be easier.
If necessary, I am able to add more comments, links or infos to illustrate my demand.

Michel

[hakre]

'theme_locale' and 'plugin_locale' filters for theme and plugin authors.

[hakre]

Please try patch against 2.8 svn. See if it fits, you should be able to hook into the filter 'theme_locale' with an additional parameter $domain if your theme supports that.

if i remember correctly, then you can place language files somewhere inside your themes directory and they get auto-loaded.

[Denis-de-Bernardy]

curious to know if you've tried something like this:

override_locale($locale) {
  if ( !in_the_loop() && !is_singular() )
    return $locale;

  // do stuff

  return $locale;
}

add_filter('locale', 'override_locale');

[michelwppi]

Thanks for your observations.

1) for hakre :
the timing when choosen .mo file (currently in theme's folder as by instance fusion a theme with localization) is downloaded (fired by load_theme_textdomain function in functions.php of current theme) is the same in WP 2.7.1 and WP 2.8
2) for Denis :
because get_locale is called inside load_theme_textdomain it is too soon for dynamic multilingual site as managed by xili-language example here ​http://dev.xiligroup.com or elsewhere.

If we want that people don't have to change the line load_theme_textdomain in functions.php of the choosen theme built by others authors, I suggest this short modification like this (around line 361 in WP 2.8 :

 * @param string $domain Unique identifier for retrieving translated strings
 */
function load_theme_textdomain($domain, $path = false) {
    if (has_filter('load_theme_textdomain')) {
do_action('load_theme_textdomain',$domain,$path);
} else {
	$locale = get_locale();

.....

}

Hope it is understandable !

Michel

[hakre]

Michel, I do not properly understand what you want to do. You want to be able to completely disable the wordpress locale string ($locale)? I do not know xili so you need to be a bit more specific.

[michelwppi]

xili-language fires load_theme_textdomain content when necessary with good parameters via a hook like in
(line 123 and 430 of source)

add_action('wp', array(&$this,'xiliml_language_head')); 
		/* 'wp' = where theme's language is defined just after query */

The wanted hook for load_theme_textdomain() is needed to disable it (because fired in functions.php) but the function called by add_action for this hook 'load_theme_textdomain' will record the value of the vars ($domain,$path) used later by the plugin which will fires, at the right time the download of the right .mo according the language via the generic load_textdomain();

I understand your worry, but a hook is the only way for avoid the recommandation as explained - ​http://dev.xiligroup.com/?p=427 - for end users without php script access...

Hope this comment is helpful !

M

[hakre]

Yes I more and more understand, but you try to do things top-down. First of all, WordPress provides a Filter and Hooking mechnism for Plugins and not the other way round.

As you write, xili translation plugin offers a hook (load_theme_textdomain) and WordPress should check for that specific Hook in the future. Right?

[michelwppi]

In other words, after lot of months of testing and scripting in the powerful Wordpress architecture :

Why the timeline of tasks and firing is important before core of WP sends the html from the server after combining query results and extend (adds-on) from plugins or functions.php of current theme?

In current themes with localization, load_theme_textdomain() is fired when WP fill the catalog of actions and filters in plugins and in theme's functions.php. So, the $locale and the .mo file for the domain of the theme is set before the wp_query is launched and before most of the hooked functions are fired.
By adding the wanted hook described in preceeding reply, during init step, the xili-language plugin - ​http://wordpress.org/extend/plugins/xili-language/ - connect a function (add_action('load_theme_textdomain',... ) to this hook. This function permit to only record the right datas (domain and path where .mo files are) and the other methods built in the plugin will use datas later to choose at the right time the right .mo according rules set by users and depending of the results of the query.

With the addition of this hook in load_theme_textdomain(), the history state of art for theme with localization will be go to a new step where these themes can be transformed in dynamic multilingual websites (*) by every users (with plugin like xili-language) and not only by webmaster with scripting knowledges as today.

Helpful ?

(*) by instance theme for polyglott countries like Canada, Belgium, and more...

[Denis-de-Bernardy]

I think you're now making a bit more sense. In other words:

• Currently, WP loads translation files before the query
• You'd like WP to load translation files *after* the query

Big -1 on the requested hooks. Plus, I'm pretty certain that this will introduce scores of potential bugs in the WP workflow.

The correct approach, imo, would be to make it so that the pomo-related stuff can be flushed and reloaded later on. That way, you can play around with the locale as much as you want, on the correct plugin hook.

[Denis-de-Bernardy]

It might even be that this is already possibly in a hacky way, btw, by modifying the pomo classes' variables.

[hakre]

Okay now I get it. I'm not a fan of having multiple languages on the blogs frontend (for plugins there are translations) because wordpress is not just made for it. I would stick with having one blog per language. You can share themes then based on the install IMHO.

[nbachiyski]

I agree with Denis, that we need functions for reloading the translations of a domain.

Here is how I see it. When loading a textdomain, it will keep internally the file it was loaded from. Then, we will have:
reload_textdomain($domain, $mofile = false), which will reload the translations from the same MO file, or alternatively a different one.

[hakre]

offering a unload_textdomain($domain) can make sense as well.

[michelwppi]

First note for hakre : As I see daily in mutilingual countries (canada, belgium and elsewhere...) WP is used in multiple languages. Matt, during his visit in WordCamp Paris confirms that WP is also very frequently used as CMS.

Second note about where to place good "hook" : by testing and reading code of a very interesting plugin ​http://devel.kostdoktorn.se/cache-translation-object/ and how the author use "locale" hook to cache translation object with a curious dummy return... It is confirmed that by placing a hook at a good place(s) inside the L10n.php functions or classes, the results will be better and well data-designed without side effects...

I continue analysis to improve xili-language plugin [ ​http://wordpress.org/extend/plugins/xili-language/] and hope to bring new comments soon.
Michel of ​http://dev.xiligroup.com

[johanee]

9686.patch might not work as some plugins and themes call load_textdomain() directly. See #11012 which proposes a filter there, and which might solve some of these problems too.

[Denis-de-Bernardy]

see also #10527

[nbachiyski]

I vote for committing that patch. It will allow plugin developers to change the locale only for a theme or a plugin.

Most of the more general issue about inflexibility of load_textdomain() was solved in #10527 The patch here just adds an unload_textdomain() function, which combined with the hooks allows changing translations on the fly.

[nacin]

(In [13330]) Introduce unload_textdomain() and add plugin_locale and theme_locale filters to load_*_textdomain() functions. Fixes #9686 props nbachiyski

Moving to 3.0 and closing out.