WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#9686 closed feature request (fixed)

Make pomo class flushable/reloadable

Reported by: michelwppi Owned by: nbachiyski
Milestone: 3.0 Priority: high
Severity: normal Version: 2.8
Component: I18N Keywords: has-patch reporter-feedback
Focuses: Cc:

Description

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

Attachments (2)

9686.patch (736 bytes) - added by hakre 6 years ago.
'theme_locale' and 'plugin_locale' filters for theme and plugin authors.
hooks-and-unload_textdomain.2.diff (3.0 KB) - added by nbachiyski 5 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 @hakre6 years ago

  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:2 @hakre6 years ago

  • Keywords multilingual localizable removed
  • Milestone 2.8 deleted
  • Priority changed from high to normal

comment:3 @hakre6 years ago

  • Type changed from feature request to enhancement

comment:5 @michelwppi6 years ago

  • Keywords theme localizable multilingual added

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

comment:6 @michelwppi6 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

@hakre6 years ago

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

comment:7 @hakre6 years ago

  • Keywords has-patch needs-testing reporter-feedback added; theme localizable multilingual removed
  • Milestone set to Future Release
  • Version set to 2.8

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.

comment:8 @Denis-de-Bernardy6 years ago

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');

comment:9 @michelwppi6 years ago

  • Cc michelwppi added

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

comment:10 @hakre6 years ago

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.

comment:11 @michelwppi6 years ago

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

comment:12 @hakre6 years ago

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?

comment:13 @michelwppi6 years ago

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

comment:14 @Denis-de-Bernardy6 years ago

  • Keywords needs-patch dev-feedback added; has-patch needs-testing removed
  • Summary changed from Please : load_theme_textdomain function be hookable to Make pomo class flushable/reloadable
  • Type changed from enhancement to feature request

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.

comment:15 @Denis-de-Bernardy6 years ago

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

comment:16 @Denis-de-Bernardy6 years ago

  • Keywords dev-feedback removed

comment:17 @hakre6 years ago

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.

comment:18 @nbachiyski6 years ago

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.

comment:19 @hakre6 years ago

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

comment:20 @michelwppi6 years ago

  • Priority changed from normal to high

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

comment:21 @johanee6 years ago

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.

comment:23 @nbachiyski5 years ago

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.

comment:24 @nbachiyski5 years ago

  • Keywords has-patch added; needs-patch removed

comment:25 @nacin5 years ago

  • Milestone changed from Future Release to 3.0
  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.