Plugins dont read general lang-file / dont use lang.inc.php

[stm999999999]

I use $serendipity['useTemplateLanguage'] = true; but this was only the base of my discovery:

I override some normal phrases in the lang-file. e.g. the text of PLUGIN_EVENT_USERPROFILES_HOBBIES.

Now I saw that in the output there is the original text and not my overriding one.

But the problem is deeper:

As I think the event-plugins do not read the normal lang-file (via lang.inc.php? anymore! Why I think so?

1) my overiding text is loaded in lang.inc.php

Code: Select all

    // The following variable can be set in serendipity_config_local.inc.php to force your templates being able to use language override includes
    if ($serendipity['useTemplateLanguage']) {
        @include (S9Y_INCLUDE_PATH . 'templates/' . $serendipity['template'] . '/' . $charset .  'lang_' . $serendipity['lang'] . '.inc.php');
        @include (S9Y_INCLUDE_PATH . 'templates/' . $serendipity['template'] . '/lang_en.inc.php');
    }

before all other lang-files. This works very fine in the past - even for the overriden text of plugin output:

PLUGIN_EVENT_USERPROFILES_HOBBIES
USERGALLERY_SEE_FULLSIZED
STATICPAGE_SEARCHRESULTS
...

in the past I saw my phrases, now there are the original-plugin-phrases in the output!

2) it is not only about my overriding phrases!

Look at user-profiles in the backend:

These plugin uses in the backend some text-variables, defined in the normal s9y-lang-file (which is included in lang.inc.php):

for example the first three field-names:

Realname
Username
E-Mail

in the past.

but now there is in the output:

Code: Select all

USERCONF_REALNAME	 
USERCONF_USERNAME	 
USERCONF_EMAIL

Only the variables, defined in the plugin-lang-file are shown right (like city, ...).

the problem is still in the latest nightly and I saw it first time in s9y_200703062342.tar.gz (but it could be older)

[garvinhicking]

Hi!

Yes, plugin languages are loaded before the actual language of the user because of some plugin requirements for the OpenID integration.

Sadly the userprofiles plugin is one of the plugins that uses constants in a place where the strings are translated from constants before the language scheme is loaded.

I just fixed that in a new version. We'll also have to fix other plugins that might have this behaviour -- but the general way how it is now sadly is not important enough to change the more required plugin API change so that plugins can be loaded before the user preferences are loaded.

Best regards,
Garvin

[stm999999999]

Yes, plugin languages are loaded before the actual language of the user

you mean the general s9y-lang-files, or? Because: the plugins are still able to see what lang is to load, or? If not: In the plugins are predefined lang-files, these are loaded as in the past, or?

Sadly the userprofiles plugin is one of the plugins that uses constants in a place where the strings are translated from constants before the language scheme is loaded.

What is the fix? Do you gave the plugin there own variables for realname etc? This would not sound so good, because variables identical in content should declared only once and at one point - I think.

I just fixed that in a new version. We'll also have to fix other plugins that might have this behaviour -- but the general way how it is now sadly is not important enough to change the more required plugin API change so that plugins can be loaded before the user preferences are loaded.

But: my first question to the "useTemplateLanguage"-feature was to override standard-s9y-phrases like "POSTED_BY" or "VIEW_EXTENDED_ENTRY" - you sad that the the normal way would be to add new variable names in the template-tpls, so no overriding is needed. This is an (in my eyes not satisfying) alternative.

BUT: If one wants to change phrases of a plugin, this is NO WAY for this!

e.g. for the output of a static-page-search-result I can copy the plugin_staticpage_searchresults.tpl to my template-folder and add new variables, but this is not good: If the plugin-author makes some changes (new output things in the search-result?) a) I have to notice it ans b) I have to adapt it to my copy of the tpl. This is annoying.

but more important: If I want to change one of the fields in the userprofiles-plugin (from Hobbies to "Tätigkeiten in der Gemeinde"). This change has to apply to the frontend output and to the backend as well. There is no tpl which I can copy and modify with new variables - and I think there are many plugins without tpls!

And as you see actualy in http://board.s9y.org/viewtopic.php?p=53147, there is still a need to easily override given phrases (no matter where it came from: s9y-core or plugins).

In my eyes s9y lost a great moment of flexibility if there is no option to override standard phrases (no difference between s9y-core and plugins)!

[garvinhicking]

Hi!

you mean the general s9y-lang-files, or? Because: the plugins are still able to see what lang is to load, or? If not: In the plugins are predefined lang-files, these are loaded as in the past, or?

I mean the first language file that is loaded, yes.

Plugin can still detect the language they are running in because the new variable that determines the variable is NOT fetched from the users configuration, but instead from a Cookie-Variable that will be set upon login.

What is the fix? Do you gave the plugin there own variables for realname etc? This would not sound so good, because variables identical in content should declared only once and at one point - I think.

I just moved the place around where the constants get transformed. The first time a constant is used, it will be translated. So I just had to ensure that the plugin uses those constants only after the global s9y language files are loaded.

BUT: If one wants to change phrases of a plugin, this is NO WAY for this!

Well, you can edit the plugin's language files. S9y tries to be flexible, but there is a limit between flexibility and functionality.

e.g. for the output of a static-page-search-result I can copy the plugin_staticpage_searchresults.tpl to my template-folder and add new variables, but this is not good: If the plugin-author makes some changes (new output things in the search-result?) a) I have to notice it ans b) I have to adapt it to my copy of the tpl. This is annoying.

Yes, but that's the price you have to pay for customization.

but more important: If I want to change one of the fields in the userprofiles-plugin (from Hobbies to "Tätigkeiten in der Gemeinde"). This change has to apply to the frontend output and to the backend as well. There is no tpl which I can copy and modify with new variables - and I think there are many plugins without tpls!

The way for this problem would be to enhance plugins to support tpls, or to offer options configuring the variable names.

And as you see actualy in http://board.s9y.org/viewtopic.php?p=53147, there is still a need to easily override given phrases (no matter where it came from: s9y-core or plugins).

I do see that need, but I see no way to make that happen.

The plugin framework now needs to be loaded BEFORE the user preferences are loaded, because we will need plugins to do things like user authentication. And that can only happen if the plugins run first in queue. But if a plugin runs first, it can no longer ensure that the loaded constants might be overriden by things that only get apparent once the user system has been initialized.

In my eyes s9y lost a great moment of flexibility if there is no option to override standard phrases (no difference between s9y-core and plugins)!

Actually in my eyes s9y has gained a lot of flexibility because now plugins can extend functionality much sooner in the s9y flow.

Caching can be improved, foreign user authentication, user redirection etc.

All that only for the loss of somebody simply editing a *.php file. I think the reward of the new thing is MUCH higher than the reward of the old thing.

Let's rephrase it: Just because you own an oil drilling rig, you can't expect people to drive fuel-filled cars forever.

Plus, the decreased language flexibility only gets to show of in very specific plugins, and not generally. In many cases you will still be able to override language settings in your personal language file.

Best regards,
Garvin

[rrichards_]

I do see that need, but I see no way to make that happen.

The plugin framework now needs to be loaded BEFORE the user preferences are loaded, because we will need plugins to do things like user authentication. And that can only happen if the plugins run first in queue. But if a plugin runs first, it can no longer ensure that the loaded constants might be overriden by things that only get apparent once the user system has been initialized.

Since we do capture the preferred language in session, would it work if the following were added right after the initial serendipity_getSessionLanguage() call?:

if (isset($_SESSION['serendipityLanguage'])) {
include(S9Y_INCLUDE_PATH . 'include/lang.inc.php');
}

This would have the same quirk as the others that if the user has a different personal language set, the first time they would get the default language and subsequent requests would use their personal setting (as it would now be set in session).

Don't know if this would fix everything, but thought i'd throw it out there.
USERCONF_REALNAME is at least resolve correctly for me in my tests.

Rob

[garvinhicking]

Hi!

if (isset($_SESSION['serendipityLanguage'])) {
include(S9Y_INCLUDE_PATH . 'include/lang.inc.php');
}

Phew. I guess currently you are far more involved in the language scheme than I am. I'm quite afraid of possible side-effects. I think we did exclude the impacts from the multilingual language-choosing plugins already...but in the end, it boils down to: "I don't know" *g*

Seems like I'd need a good and thorough look at these things again, but I doubt I'll find time for this anytime soon to wrap my head around it ;(

Regards,
Garvin

[stm999999999]

Is there any progress in this question?

For me I have to say I did not (technicaly) understand all the things written above. so the following could sounds amateurish:

Garvin, you said you moved something about where the constants get transformed.

So I just had to ensure that the plugin uses those constants only after the global s9y language files are loaded.

Shouldn't this solve my problems?

Because plugins like usergallery, userprofiles or the search, all this plugins have no need to act and load lang-files so early (like a authentication plugin)