Logging form after upgrade

mikulas · 2020-06-18 07:32:18

After upgrading to Textpattern 4.8.1, the form on the login page is in English only. Switching languages, cleaning cache and reloading the page will not help.

phiw13 · 2020-06-18 08:30:21

Did you check the Languages panel to see if all active languages where updated? It should happen automatically, but who knows.

(also, to make sure, did you upload the language files ? found in the textpattern/lang directory)

gaekwad · 2020-06-18 09:21:04

mikulas wrote #323825:

After upgrading to Textpattern 4.8.1, the form on the login page is in English only. Switching languages, cleaning cache and reloading the page will not help.

Visit the languages page (/textpattern/index.php?event=lang), then check if Čeština is installed. If it is installed, try removing it and installing again.

Bloke · 2020-06-18 09:55:49

mikulas wrote #323825:

After upgrading to Textpattern 4.8.1, the form on the login page is in English only.

That is interesting. It’s supposed to use the current public site language, whatever that may be. It appears that there’s a bug in gTxt() where it does this on the login page:

Checks if you’re on the admin side: yes.
Asks the database for the current admin language because it considers the login form an admin task.
Cannot retrieve the admin language because it’s a per-user setting and when you’re logged out, there’s no username available.
Falls back on the site default: English.

Thus the login form will always be English.

I would like to fix this once and for all. Part of me thinks using the public site language is still not wonderful UX, because not all contributors will use that language. Although I suppose it’s a fair assumption that most will, if the site is rendered in that language.

In the absence of knowing the user, there are a few things we could do. The most obvious one is that when changing admin-language, not only set a pref, but set a cookie or localStorage object with that name. Then, after logging out, we can still detect that on the login page and render the login screen in the language you last used. Fallback on English if there’s no cookie/localStorage.

Would that be useful? Or should we revert to rendering it in the public language, regardless of what was last used as an admin-side language?

Last edited by Bloke (2020-06-18 09:56:28)

gaekwad · 2020-06-18 09:57:28

See also github.com/textpattern/textpattern/issues/1288 for additional discussion.

Bloke · 2020-06-18 09:59:40

Actually, Pete, that would be even better. I’d forgotten about that option. Thanks for the reminder.

phiw13 · 2020-06-18 10:12:47

Bloke wrote #323831:

The most obvious one is that when changing admin-language, not only set a pref, but set a cookie or localStorage object with that name. Then, after logging out, we can still detect that on the login page and render the login screen in the language you last used. Fallback on English if there’s no cookie/localStorage.

When first reading (scanning, actually) your reply in the email notification I thought the same, storing that pref in localStorage. There is a potential privacy issue in this, as this can eventually reveal more info about the previous user who logged in from the machine (think of a share environment). how big that issue is a matter of appreciation.

But otherwise, yeah that would eventually be a nice option on single user devices.

Last edited by phiw13 (2020-06-18 10:15:29)

Bloke · 2020-06-18 10:37:55

phiw13 wrote #323835:

There is a potential privacy issue in this, as this can eventually reveal more info about the previous user who logged in from the machine

That’s a good point. Hmmmm.

Reading through the issue thread again, there’s some food for thought there. Primary things to consider:

Using a language (?lang=) in the URL to preset the login screen language is a nice way for people to tinker with it. If that’s present, any language chooser we add to the login panel would default to that value – assuming that language is installed (otherwise, it’d be missing form the dropdown anyway and they’d get English).
Position of the language chooser on the login form. Putting it first – above the login and password boxes – is not quite as friendly as putting it elsewhere. Login is the primary function. But putting it lower down the page means a potentially annoying disconnect: 1) Enter username and password, 2) select language… grrr, the page refreshes, losing your username and password that were typed.
Carrying the selected language forward and auto-setting the admin-side language to the one chosen on the login screen seems logical to me.
When sending password invites or login resets, an additional step could appear from the multi-edit tool. ‘Select language’. This would send the email with the given ?lang= set in the login/password reset link. Downside: the same language would be used for all selected users.
Alternatively, when performing an Admin->Users password reset/invite, we could read that user’s admin language from the database. Thus, each user’s link would potentially be different based on what they have set now. If they’ve never logged in, they’d get English. Downside: for new users there’d be no value so they’d get English… unless on the Admin->Users->New Author step, we add a language dropdown, which sets that user’s admin language before they’ve even logged in for the first time. That has the benefit that the original invite could be sent in the nominated language instead of always using the admin language of the person who created the user.
Would require some changes to the login process to read the ?lang= and act accordingly, passing it forward. Would also requires some changes to the password reset system so that the target user’s admin language was used to render email messages.
Without storing a cookie/localStorage, we could default to the public site language. That does (potentially) mean that users who visit the login panel don’t see it in their chosen language, BUT a) if they bookmark the URL that contains the ?lang= in it then they will at least see it in the chosen language. b) They can still alter the language from the dropdown on the login panel. And when they log in, this is passed forward to set their admin-side experience, overwriting whatever they had set from the Admin->Languages panel.

Lots to think about. But once we choose a way of working, not a terrible amount of work. And whatever we decide to do, no language chooser at all appears on the login panel if there’s only one language installed.

Last edited by Bloke (2020-06-18 10:43:24)

Bloke · 2020-06-19 14:18:46

I’m testing something locally for 4.8.2 which adds localisation for:

Account activation messages.
Password reset messages.
Language selection on the login panel.
Passing that language to the admin side on login so it defines your ongoing experience (you can still change it from the Languages panel at any time).

Bit of work to go yet but it’s working well so far. Watch this space.

Bloke · 2020-06-21 14:13:45

The 4.8.2 branch now has a new language selector on the login panel. If there’s only one language installed, it’ll be omitted. So if you don’t see it right away, log in, go to the Languages panel and install some (P.S. there’s a bug in the Languages panel when removing langs: I’ll fix that next).

Anyway, when you log out, you’ll see a selector above the name/password boxes that defaults to the language you were using on the admin side. A few language strings need moving yet, so you’ll see untranslated strings in a couple of places at the moment.

The idea is:

When you visit the login panel, you can choose a language to log in with. If you change the selector, the login panel refreshes immediately (note the URL adds ?lang=).
When you log in successfully, whatever language you chose in the login panel will be set as your admin-side language experience. You can change this as usual from the Languages panel.
You (or an admin) can now also alter the language from the Admin->Users->Edit panel (just a shortcut).
When creating new authors, you can define a language for the new user. When you save the new author, the welcome message will be sent in that language. I need to test this, but if you set their language as the ‘empty’ entry at the top of the list, it’ll leave things alone and they’ll get the welcome message in your language. The only reason the empty entry is there, is just in case anyone upgrades and doesn’t have a language_ui set. That could potentially show incorrect information (e.g. if no language is set in their account, and there was no empty entry in the dropdown, then it would pick the first one, which might lead you to think that this user has the first language set).
From the multi-edit tool, if you send password resets or activation requests to a bunch of users, each one will receive the message in their current admin-side language.
During Txp setup, the language you chose during installation will be passed forward to the login screen form the final step. Thus your login panel will appear in that language for a more seamless experience.
You can bookmark the new login panel with the lang identifier in the URL if you want to have the language default to that one.
You can tinker with the URL parameter if you like to display the login panel in a different language BUT you can only display it in one of the installed languages. So if you set ?lang=pl but Polish is not installed, you’ll get whatever language was first installed.

Hope this is useful. It certainly feels better to me. Please test it as widely as you can to check it performs well. And I’ll get the language strings moved so things look a bit better in due course, if we like the way this works.

Last edited by Bloke (2020-06-21 14:15:33)

gaekwad · 2020-06-21 14:21:05

Anyone reading this as a result of Bloke’s post above, the 4.8.2 branch dev demo will be rebuilt on schedule in about 40 minutes from this post time stamp, so you will be able to try it out.

dev-demo.textpattern.co/4.8.2/

gaekwad · 2020-06-21 15:37:57

Bloke wrote #323874:

The 4.8.2 branch now has a new language selector on the login panel. If there’s only one language installed, it’ll be omitted.

On the Textpattern tip, we have language in [prefs] – could we move that to [public] and tick off the dropdown box translation?

Textpattern CMS

Textpattern CMS support forum

#1 2020-06-18 07:32:18