Languages bundled in core

phiw13 · 2017-11-22 08:18:56

Overall, it works well. But for old installs that are upgrading, one must delete + reinstall (all) languages. Plugin are still a bit of an issue of course, even on a fresh install.

I saw one weird issue, after toggling from English to some_language and vice versa. I have@etc_cache@ installed (correct En strings); after toggling the extension tab would show the name with the raw string (even toggling TO English).

Bloke · 2017-11-22 09:35:37

phiw13 wrote #307927:

for old installs that are upgrading, one must delete + reinstall (all) languages.

Hmm, you shouldn’t have to delete them. If you just Update a language it’ll pull in any new strings from the file and create any fallbacks in your nominated default language (en if omitted). If your mileage varies, we’ll have to investigate why and fix it.

Plugin are still a bit of an issue of course, even on a fresh install.

If they have Textpacks bundled inside them, they’ll be stored internally from now on when they are installed. For upgrades, this means that to benefit from this feature you’ll need to reinstall your plugins (but quite a few will need upgrading anyway when a new version of Txp hits the shelves). For fresh installs, the language string insertion should be automatic. If it’s not, please raise an issue and we’ll investigate, because that’s how it’s supposed to work.

after toggling from English to some_language and vice versa. I have@etc_cache@ installed (correct En strings); after toggling the extension tab would show the name with the raw string (even toggling TO English).

That’s not supposed to happen. Is it repeatable enough to raise an issue so we can check it out and patch it? Does it occur only on that plugin or do others suffer? Is this when you switch UI language or site language?

Thanks for testing and for the report. Need to get all this nailed down and working seamlessly soon!

etc · 2017-11-22 11:30:30

phiw13 wrote #307927:

I saw one weird issue, after toggling from English to some_language and vice versa. I have@etc_cache@ installed (correct En strings); after toggling the extension tab would show the name with the raw string (even toggling TO English).

It could be just because the user language is not immediately switched (which is an issue, as for themes). Reloading should fix that, please check.

phiw13 · 2017-11-22 12:03:44

etc wrote #307931:

It could be just because the user language is not immediately switched (which is an issue, as for themes). Reloading should fix that, please check.

Yes, once you move away from the languages panel, it rectifies itself (at least for English).

Bloke wrote #307929:

… lots …

I’ll need to read you post more carefully, and then test again. I’ll get back to you soonish.

One thing though – all I’m testing atm is backend stuff, so when I note “toggle language” it is all about the “user language” / UI language.

Bloke · 2017-11-22 12:21:48

etc wrote #307931:

It could be just because the user language is not immediately switched.

It’s supposed to reload as soon as it possibly can after switching. I thought the panel force-reloads textarray from the DB when you switch. At least, I’m sure it did when I merged the lang changes into dev the other week. There’s a possibilty it does so after rendering the header – but I swear I checked that and it changes the menu bar immediately.

Might have missed something. Will have to run some tests. If anyone has any STR where this is repeatable, please share and I’ll try to reproduce it.

phiw13 · 2017-11-23 06:05:34

Bloke wrote #307929:

Hmm, you shouldn’t have to delete them. If you just Update a language it’ll pull in any new strings from the file and create any fallbacks in your nominated default language (en if omitted). If your mileage varies, we’ll have to investigate why and fix it.

I had Deutsch installed on my playground site (en-GB as defaults) which has used the bleeding edge code since forever. When the languages branch landed on /dev, I updated said language. A few days later (and prolly further updates to the language – the thing is, the language displayed as “up-to-date” on the Language panel), I actually selected it as UI language. To my surprise the string User language on the Language panel displayed as a raw string. There was another string (or two?) somewhere that failed, I forgot where though. Deleting and reinstalling the language fixed those issues.

I‘ll fetch the DB of one live site that runs on TXP4.6.2 with a couple of languages installed and install it locally on 4.6.2 then upgrade to 4.7-latest and see what happens. Probably in a few days, if you think about some (easy-to-understand-for-my-old-brain) debug code that you can throw in to get more details, let us know…

(plugins / extension menu) That’s not supposed to happen. Is it repeatable enough to raise an issue so we can check it out and patch it? Does it occur only on that plugin or do others suffer? Is this when you switch UI language or site language?

Here are some STR:

On an install created after the languages branch landed, I added the following plugins: etc_cache and smd_bio, both add an entry under the extensions menu. I verified that the strings for both displayed correctly when using en as UI language.

Switch to any other language. Click to open the Extensions menu, you’ll see the name of both plugins displayed as expected. Now go to any other panel (Diagnostics is fine), click again on the extensions menu: raw strings.

Return to the languages panel and switch back to English, click on the extensions menu: raw strings. Go to any other tab, click the extensions menu: OK.

(But that is actually a minor issue. How often do you access the languages panel?)

If they have Textpacks bundled inside them, they’ll be stored internally from now on when they are installed. For upgrades, this means that to benefit from this feature you’ll need to reinstall your plugins (but quite a few will need upgrading anyway when a new version of Txp hits the shelves). For fresh installs, the language string insertion should be automatic. If it’s not, please raise an issue and we’ll investigate, because that’s how it’s supposed to work.

When the UI-language is any other language than en or en-gb (the default), those plugins mentioned above display raw strings everywhere in the UI anywhere where they are used. I also tested this with smd_thumbnails, latest beta from github, after installing its textpack.

Both plugin issues are repeatable across 3 install: the new one, my trusted playground on localhost and a dummy install on a live server (Dreamhost).

Bloke · 2017-11-23 10:11:48

phiw13 wrote #307947:

To my surprise the string User language on the Language panel displayed as a raw string.

Since that’s one of the new batch of strings that are yet to be translated in many languages, I’ll use that as a starting point and try to recreate this. Thanks for the report. Any more detail would be great if you can dig it up. Putting your site in debug mode and looking at the admin-side trace log will probably be enough to figure out what’s going on when it’s loading stuff from txp_lang.

Switch to any other language. Click to open the Extensions menu, you’ll see the name of both plugins displayed as expected. Now go to any other panel (Diagnostics is fine), click again on the extensions menu: raw strings. Return to the languages panel and switch back to English, click on the extensions menu: raw strings. Go to any other tab, click the extensions menu: OK.

Something odd going on here for sure. I’ll check it out.

When the UI-language is any other language than en or en-gb (the default), those plugins mentioned above display raw strings everywhere in the UI anywhere where they are used.

This I can understand if the plugin has no strings defined in the currently-selected language. When you switch language to one the plugin doesn’t speak, no reinstallation and therefore no fallback string replacement takes place.

In theory – untested right now – if you were to go and modify the Textpack file of the language you were using (e.g. de: add a space, delete it, save file so the timestamp is newer than the DB stamp of that language) you should then be able to Update the language.

At that point of reinstallation, any strings in the current language – including the empty plugin ones – will be checked and fallback strings will be installed. You should then see the plugin’s strings in fallback English.

At any point, if you switch to a language that the plugin does have a pack for, all should be fine. If you switch to a different language that the plugin does not have a pack for, you’ll see raw strings again until you do the Update dance for that language (or reinstall the plugin, which will trigger a language update on the current language file).

This is a bit of an annoyance so we could probably do with some thought put into how to address this. Maybe we should treat non-core strings (those with an owner) as special cases and use fallbacks on the fly – expensive in terms of processing though. Or maybe when you switch language – UI or site – just perform a ‘partial install’ of all non-core strings so any untranslated plugin strings get fallbacks inserted.

Anyone got any thoughts on this or ways to improve the situation?

EDIT: Or try this patch from makss which may help matters significantly as you can just go to the Languages panel and click Update after installing a plugin to do the replacement dance without mucking around in the file system.

Last edited by Bloke (2017-11-23 10:18:29)

Bloke · 2017-11-25 00:29:32

phiw13 wrote #307947:

Switch to any other language. Click to open the Extensions menu, you’ll see the name of both plugins displayed as expected. Now go to any other panel (Diagnostics is fine), click again on the extensions menu: raw strings.

Delving deeper into this, we’re at the mercy of the Txp loading system. When you select a new admin language, the processing goes like this:

Kick off page load on the Languages panel. Txp has no idea who the user is at this point, because we need to divert to txp_auth if the session has expired or the user is not logged in.
Since we need to display something on the txp_auth page – and need to render the theme’s header bar too on the auth page – we only have one option: load the strings for the language of the public site. In fact, you’ll notice this if your UI language and public language differ: logout then refresh to visit the login page and it’ll be rendered in the public language.
Once you’ve passed the authentication/cookie check, we know the user and can therefore fetch the user’s prefs.
Since we now have the user’s prefs, we can get the user’s preferred admin language and load the strings. But, crucially, it’s still set to the language you just migrated from, because at this point we haven’t stored the new language as we haven’t loaded the panel that will complete the process.
The plugins are loaded. The problem is, as far as they are concerned, you’re still running the site in the old language. The menu items are set up here (plugins register tabs, and request privileges, etc) so if the plugin strings don’t exist in the language you just used, Txp registers the tab name (menu name) in the raw string. Conversely, if you do have the strings in the language you just migrated from, the plugin will be registered with its correct string name during this page load.
After a few more checks, the Languages panel is loaded.
The panel then checks the step and decrees it’s time to set the admin language. It writes this to the database and the prefs AND fetches the strings for the desired language.
The entire page is thus rendered in the desired language, except for the stuff that was registered prior to the language being switched. This unfortunately, means plugins are left with outdated information on this first page load after a language switch.

tl;dr Short of refreshing the page twice when you change admin language, or committing the language change via AJAX and then refreshing the page, there’s not much we can do about it, sorry.

Oleg / makss: what do you think? Is it worth firing off the save_language_ui() call as an AJAX call and if it returns success, refresh the page and pass the success message, or if it fails, call announce with the fail message? Is that possible?

One further side note: When the language is changed, it currently renders the ‘preferences saved’ message in the language that you just left. Would you expect it to be rendered in the language you just loaded instead? So if you switch to French, you get ‘preferences saved’ in French? It’s a one-line switch if people think this is better than using the old language.

Votes please!

Last edited by Bloke (2017-11-25 00:31:22)

phiw13 · 2017-11-25 02:01:09

Bloke wrote #307982:

Delving deeper into this, we’re at the mercy of the Txp loading system. When you select a new admin language, the processing goes like this: (…)

tl;dr Short of refreshing the page twice when you change admin language, or committing the language change via AJAX and then refreshing the page, there’s not much we can do about it, sorry.

Thanks for explaining. As I said, it is a minor issue – and a one time occurence – testers may change language more often, but a regular user ? Once she has chosen her preferred UI language, she’ll have no reason to change it again, right ?

One further side note: When the language is changed, it currently renders the ‘preferences saved’ message in the language that you just left. Would you expect it to be rendered in the language you just loaded instead? So if you switch to French, you get ‘preferences saved’ in French? It’s a one-line switch if people think this is better than using the old language.

Votes please!

I had been thinking about that, and meant to comment, but it slipped my mind. I think the message should read in the “new” language.

Bloke · 2017-11-25 02:28:03

phiw13 wrote #307984:

Once she has chosen her preferred UI language, she’ll have no reason to change it again, right ?

I would expect so. This is a minor inconvenience that we could get round if we wanted to, but unless it’s an easy fix I’m not super bothered.

I think the message should read in the “new” language.

I concur. I’ve changed it in my local install but it’ll be bundled up with a whole raft of other tweaks (probably tomorrow now). I’ve just refactored a load of language-related code and think I’ve managed to eradicate one more global in the process: $textarray. Yay! Just gotta test if setup still works…

makss · 2017-11-25 10:59:16

Bloke wrote #307982:

Short of refreshing the page twice when you change admin language, or committing the language change via AJAX and then refreshing the page

Attempt without using AJAX

I will try to solve the issue of language packs of plugins(no existing translations) next week.

Bloke · 2017-11-26 15:17:17

Thanks, makss.

Everyone, please check out the refactored lang handling process in the lang-tweaks branch. This is an attempt to encapsulate the lang strings a little further by removing the reliance on the global $textarray and making strings a class variable of L10n\Lang.php.

I had to introduce a way for things like setup to push its own strings to the class so that it could load its strings from file and inject them into the class. We could probably do this by adding a loadFromFile() method (or similar) and use the refactored methods in the class a little more ingeniously. Maybe someone can improve on what’s there now?

But as it stands it seems to work fine and I’m happy to see the end of another global variable. Please everyone, test it – including setup. If there are no objections to this workflow in a few days I’ll merge it to dev.

Side note: this doesn’t have makss’ recent patch for the double-refresh on language switch. Maybe we can build on this lang-tweaks branch to see about fixing that and the plugin language handling?

makss · 2017-11-27 10:59:28

Bloke wrote #308007:

Everyone, please check out the refactored lang handling process in the lang-tweaks branch. This is an attempt to encapsulate the lang strings a little further by removing the reliance on the global $textarray and making strings a class variable of L10n\Lang.php.

Great idea! I tested everything works fine, can merge with dev.

Side note: this doesn’t have makss’ recent patch for the double-refresh on language switch. Maybe we can build on this lang-tweaks branch to see about fixing that and the plugin language handling?

As you will be more comfortable, my patches can make the code not stable for several days.

Bloke · 2017-11-27 11:54:15

Thanks for testing, makss. I’ll merge this to dev today, then you can merge it and play with the plugin/language thing in your branch.

EDIT: I’ve made one other enhancement to the Languages panel in this branch: a count of the number of other users that are using a language as their UI. This is so that admins know that deleting a language has fallout for the given list of users. Clicking the number takes you to the Users panel and lists the affected users, but I’m not sure this is such a hot idea as it might break the GET params bombshelter if there are hundreds of users. Experimental. Thoughts?

Last edited by Bloke (2017-11-27 12:43:28)

Bloke · 2017-11-27 11:57:44

makss wrote #308018:

my patches can make the code not stable for several days.

Mine too :-) That’s why we test features in branches!

It’s especially important to try and keep the dev branch reasonably clean/usable now, given that Pete’s offering it live every few hours thanks to your awesome auto-installer.

Textpattern CMS support forum

#16 2017-11-22 08:18:56

Re: Languages bundled in core

#17 2017-11-22 09:35:37

Re: Languages bundled in core

phiw13 wrote #307927:

#18 2017-11-22 11:30:30

Re: Languages bundled in core

phiw13 wrote #307927:

#19 2017-11-22 12:03:44

Re: Languages bundled in core

etc wrote #307931:

Bloke wrote #307929:

#20 2017-11-22 12:21:48

Re: Languages bundled in core

etc wrote #307931:

#21 2017-11-23 06:05:34

Re: Languages bundled in core

Bloke wrote #307929:

#22 2017-11-23 10:11:48

Re: Languages bundled in core

phiw13 wrote #307947:

#23 2017-11-25 00:29:32

Re: Languages bundled in core

phiw13 wrote #307947:

#24 2017-11-25 02:01:09

Re: Languages bundled in core

Bloke wrote #307982:

#25 2017-11-25 02:28:03

Re: Languages bundled in core

phiw13 wrote #307984:

#26 2017-11-25 10:59:16

Re: Languages bundled in core

Bloke wrote #307982:

#27 2017-11-26 15:17:17

Re: Languages bundled in core

#28 2017-11-27 10:59:28

Re: Languages bundled in core

Bloke wrote #308007:

#29 2017-11-27 11:54:15

Re: Languages bundled in core

#30 2017-11-27 11:57:44

Re: Languages bundled in core

makss wrote #308018:

Board footer