Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2018-03-24 11:57:42

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Language fallback if language textpack does not exist?

I noticed with glz_custom_fields that if one switches UI language and there is no textpack for the new language, you get just glz_cf_edit_position etc. which is logical but not very helpful. For the unitiated, it makes it look like the plugin is broken.

Is there a way to make it fall back to English if the textpack does not exist? That way it would at least read properly, even if not in the right language.

It’s just as possible that I haven’t implemented it properly: I threw out all of Gerhard’s ancient proprietary language string code and switched to a textpack and the gTxt(). Maybe I forgot something?


TXP Builders – finely-crafted code, design and txp

Offline

#2 2018-03-24 21:27:23

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Language fallback if language textpack does not exist?

This is a tough one to crack. We have lots of forces at play, so let’s define them:

  1. Core language strings available to the system, on disk, for a given site.
  2. Language strings installed in someone’s database for that site, for any supported language. A mixture of core and user-defined (plugin) strings.
  3. Active language on the public site.
  4. Language(s) actively used on the admin-side by authors.
  5. Language Textpacks supported by plugins.

From 4.7.0 onwards, if you install any plugin that has a Textpack bundled in it, ALL its strings are stashed along with the plugin in the txp_plugin table. This is just for safekeeping. They are not necessarily installed.

If you happen to have one or more of the supported languages installed in your site at the moment you install the plugin, the relevant strings will also be added to the database in the txp_lang table. If some of those strings are missing (because the plugin Textpack strings for that language are incomplete, the language strings from the default language (en by default, but may be changed by an admin in config.php) are installed as fallbacks.

Thus, after installing a plugin, you will have strings available for all installed languages. And any partially-completed packs will have the gaps filled by strings from the default language. At least, you should have. If it doesn’t work that way, it’s a bug!

After that, if you add a new language at any time AND the plugin Textpack stashed in the txp_plugin table for ANY plugin contains strings designated for that language, they will be installed.

At that point, it should also add fallback strings if there are any strings missing. Maybe this is not happening. If not, we need to figure out why and fix it.

[

EDIT: part of the reason may be that how do we know a string is missing in the current language compared with the default language? All we have to go on is “the pack in the language that is being installed from the Admin->Languages panel”. Core grabs that pack, iterates over the strings and adds them. Great. It has no idea that there are others defined for the default language: it doesn’t look there.

Further, who’s to say that the default language contains all strings? What is the default language exactly? The first one in the list defined in the plugin Textpack? The default language defined by the admin in config.php? What if we could determine the default language and it contained fewer strings than the one being installed?

]

If the language is entirely not supported by the plugin… umm I need to check. Presumably it’s skipped entirely, which would explain the entirely missing strings, and subsequent raw string output. Is this what we want? Should it install the strings from the default language, if it exists, and only after it’s exhausted that avenue, shrug its shoulders?

I’d like to verify these last two points with some examples and tests because it needs to be right if we possibly can.

Last edited by Bloke (2018-03-24 22:51:43)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#3 2018-03-25 01:28:34

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Language fallback if language textpack does not exist?

Okay, after much digging it seems that I’d made a fatal assumption with PHP’s array_merge(): it doesn’t actually merge complex arrays. What it was actually doing when I dumped out all the final contents was appending stuff into monolithic structures, all with the same language identifiers.

I’ve fallen back on doing a manual merge, which is a bit of a hack, especially given that strings may be:

  • In a different order to the fallback pack.
  • Omitted from the fallback pack.

But it seems to work in my testing. Now, when you install a plugin or install a new language (whether supported or not by the plugin pack) the entire string set from the fallback language is used to populate the gaps. Thus if the language is partially represented, you still get a full set of strings. If a language is completely unrepresented, the entire pack uses the fallback strings.

Because of the nature of this change I’ve opened a new branch lang-tweaks. Please test this and let me know if it’s any better.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB