Wrong Language Phrases

[bhsmither]

Re-visiting #512 and #1958.

Install a foreign language - es-ES, for example. In admin, be sure the admin is using the store's default language - which is other than the newly installed foreign language. Clear the cache. Verify that the following files do not exist (the cache folder should be empty): .definitions.cache .definition_data.cache *.(any language code).cache

In admin, Languages, click the edit icon for es-ES.

Observe that in many places in the common GUI areas, phrases from es-ES are being used.

I am still tracing out the code flow, but I believe that the language to be edited is being used in the final stages of constructing the common GUI areas.

[bhsmither]

Considering that the cache is not used in admin, checking for the cached files probably does not contribute to this issue.

[bhsmither]

I have a much better idea of what is happening.

In Hookloader->load(), eventually a call is made to $this->_plugin language(). After a call to Language->loadDefinitions() to add the plugin's definitions to Language->_language_strings, and then a call to Language->loadLanguageXML() to add (something else) to Language->_language_strings, there is a call to Language->assignLang() that gives to Smarty template variable "LANG" the current slate of _language_strings.

Loading in a language for editing also uses loadDefinitions() and loadLanguageXML() -- overloading _language_strings from what was initially created during CubeCart's wake-up cycle.

THEN, any other plugin hook that gets loaded(*) after CubeCart deals with loading the language to be edited will cause the current slate of _language_strings, including the now foreign language's strings, to be re-assigned to Smarty template variable "LANG".

And there are a number of hookloaders available during the final wrap-up of building a page for Smarty to compile.

(*)Note: only if Hookloader->_loaded_lang[$plugin] is not set will the call to assignLang() be called.

It appears that the first time Hookloader deals with actually processing a hook from a plugin, is _loaded_lang[$plugin'] set.

So, maybe (not tried) when enumerating all plugin hooks (_build_hooks_list()), make a call to _plugin_language() to build a fairly complete _language_strings before overloading it with the foreign language's definitions.

Or... ask the Language class to not overload _language_strings with the foreign language's definitions. Instead, ask the Language class to segregate them so that settings.language.inc.php can request those specifically for Smarty's task variables "SECTIONS" and "MODULES".

[bhsmither]

Well, there is $this->_language_strings_def that is used in getGroups() and assigned to "SECTIONS" in settings.language.inc.php.

But _language_strings is the target of investigation.

[abrookbanks]

I've copied the commentary from the language search below:

Commentary in reference to GitHub issue #2839:

This search capability looks into the language strings of the language chosen to edit. Other than the exception mentioned below, the search looks nowhere else.

Once a language has been chosen and the admin is taken to the next page, the language strings for that language are available to be scanned. Regarding #2839, if a hookloader catches a plugin's hook prior to the search code fetching the available language strings, the strings from that plugin's language file will also be scanned, because CubeCart has incorporated them. For plugins that are first seen after the fetch, it is too late as their language strings were not yet incorporated.

This is a simple search: if the exact search word/phrase can be found in a string, it will be included in a list of results.

Being a simple search, there will be no matches on phrases that use sprintf() placeholders, expecting to find the dynamic content as seen displayed.

TODO: After the admin has chosen a group to examine, the Search input no longer works because the Group selector has a valid value for the form element 'type' -- which takes precedence in settings.language.inc.php. This can probably be fixed by making this edit (if desired) in admin.js, near line 274:

    }), $("input:submit.update").click(function() {
        $("select.required").removeClass("required").attr('name',null)

Check for collateral damage elsewhere!

TODO: Create language strings to replace the hard-coded phrases used in the new code.

WAITING: If the solution to #2839 causes the location of where the search function fetches the strings to be scanned to have changed its content, this code will need to adjust.