Language choice by authors into the "Authors" page.

Pat64 · 2016-03-02 10:19:57

@Devs

What do you think about this new feature for the current TXP 4.6 branch?

Choosing the language by authors within the “Authors page” for the Textpattern interface (aka wet_native but with a much better support).

Bloke · 2016-03-02 10:49:24

Pat64 wrote #298104:

Choosing the language by authors within the “Authors page” for the Textpattern interface (aka wet_native but with a much better support).

I’d love it, but probably not this close to a 4.6 release. Unless someone thinks it can be shoehorned in very quickly. It’s not a massive undertaking, after all.

With my anti-project-creep hat on, I think this makes sense to include as we move towards a more multi-lingual Textpattern experience out of the box, which is slated for a version or three’s time.

In tandem with this and a few table changes to allow multi-lingual content to be stored, I’m considering a new callback in load_lang() which would allow plugins to alter language strings far more simply than today.

Pat64 · 2016-03-02 11:43:35

I just sent a donation to Mister Blocke because I love its answer (and to motivate him).

http://stefdawson.com/images/Mugs/128.jpg

;)

Last edited by Pat64 (2016-03-02 11:47:41)

Bloke · 2016-03-02 12:14:07

Pat64 wrote #298107:

I just sent a donation to Mister Blocke because I love its answer (and to motivate him).

Motivation received with thanks :-)

We should probably raise this as an enhancement Issue on GitHub so it remains on our radar. The whole multi-lingual thing could do with its own Issue, with a list of things to check off as we move towards completion of the feature.

NicolasGraph · 2016-03-03 09:27:29

Just in case you missed it: wet_native already allow users to choose an admin-side langage under the Authors tab.

philwareham · 2016-03-03 11:25:02

I’ve opened an issue to track this on GitHub for you.

Pat64 · 2016-03-08 17:55:41

;)
Thank you Phil.

Bloke · 2016-11-26 01:52:45

Part one of this is done so wet_native is no longer required. Note that it’s not implemented on the Authors panel (as per the request), but on the Admin->Languages panel so that users may freely choose their own admin-side language. Currently, they have gained the ability to upload Textpacks, which permits overriding language strings. This will probably be revisited in the coming weeks, because it should be an administrator-only task.

Until the panel layout is improved, the Show details toggle isn’t much use to non-privileged users. That will also be addressed soon.

Finally, for sites with only a single language installed, we may elect to hide the entire Languages menu/panel from non-privileged users. This may require some alterations to the way we build menus, so this will be deferred to a later date.

Last edited by Bloke (2016-11-26 01:54:35)

Pat64 · 2016-11-26 05:54:41

Thank you lot, Steff.

I started to play with and all is perfect ;)

phiw13 · 2016-11-26 07:31:35

Great so far ! One plugin less, more flexibility to the various users.

Bloke wrote #303001:

Currently, they have gained the ability to upload Textpacks, which permits overriding language strings. This will probably be revisited in the coming weeks, because it should be an administrator-only task.

That seriously scares me (as an administrator). Only an admin should be able to do that (or at maximum Publisher and Managing Editor).

Bloke · 2016-11-26 11:57:49

phiw13 wrote #303003:

[Textpack upload] Only an admin should be able to do that (or at maximum Publisher and Managing Editor).

You’re right. I’ll fix that as part of Phil’s language panel proposal. I like the idea of the panel, but I don’t know if a grid is as easy to scan, visually, to find a language or see if one’s available for update. The current list/table is a waste of space, though.

I wonder if there’s some neat way to filter the grid to only show installed languages or all languages – something that’s remembered on each visit to the page. Less to parse with your eyes to see if an update is required to the currently installed languages, but only a click away to reveal all if you want to add a new one?

phiw13 · 2016-11-26 12:44:17

Bloke wrote #303005:

You’re right. I’ll fix that as part of Phil’s language panel proposal. I like the idea of the panel, but I don’t know if a grid is as easy to scan, visually, to find a language or see if one’s available for update. The current list/table is a waste of space, though.

Something like this (quick WIP / draft).

I’ve looking at it the past few days (un poquito solo), I think the color coding makes things visually more complicated than needed. Quick idea: just bolding the string “installed” would be better and eventually adding some sort of icon in the top/right corner for the “installed” cells. The .warning class could then be used to highlight the cell when an update is available.

I wonder if there’s some neat way to filter the grid to only show installed languages or all languages – something that’s remembered on each visit to the page. Less to parse with your eyes to see if an update is required to the currently installed languages, but only a click away to reveal all if you want to add a new one?

That would be kinda nice, I think.

Last edited by phiw13 (2016-11-26 13:00:23)

jakob · 2016-11-26 14:10:57

As pretty as it looks and I admire what Phil has done for the backend, I honestly think the simple list view is better in this particular case. I suspect the vast majority of sites have 1 or 2, perhaps 3 languages installed. The only time you really need the long list is when choosing your language from the long list in the first place, and then my guess is that most people look alphabetically for their country/language. That’s easier to do when they are listed alphabetically beneath one another rather than scanning a grid.

Could we not simply put the installed languages at the top of the list and the “other languages” below them?

Can’t wait for this grid to surface, though! That’s where a grid would be really useful…

PS: Great news on the per-author admin language settings. That’s really useful.

Bloke · 2016-11-26 15:50:24

jakob wrote #303007:

the simple list view is better in this particular case.

The more I look at it, the more I’m beginning to agree (sorry, Phil!)

I was looking for a language earlier for some locale testing and had to scroll back and forth a few times to find it. Might just be me, though.

For finding the currently installed languages, phiw13’s mockup is way easier. They jump out at you and are nice and easy to spot. That still leaves the (albeit comparatively infrequent) issue of finding a new language to install from the sea of remaining blocks. In this instance, I like jakob’s idea of putting the installed languages at the top of a list, then the remainder alphabetically (by code, as they are now).

But the list concept does seem a bit wasteful of space. The current table-based thing is a mess, and maybe a single list with install/remove buttons and the date is enough. Both the grid and list work well on mobile as they’re only one-block wide. But as you expand, a single list starts to look puny in the middle of the panel. Dunno the answer.

One other thing to consider is non-privileged users. Do we need to show the installed languages at all? Is that information of use, considering they can’t do anything about it? Does the last updated date mean anything to them?

If we omit the entire list for those that have no need of it, the UI is a lot easier to build. But if they’re not getting the textarea for Tetpacks and not getting any languages shown, and don’t have the ability to alter the front-side language, it makes the panel really sparse: just a single dropdown for their own admin-side language!

EDIT: Mind you, on the Users panel, non-privileged users get a single button to change their password, so it’s not without precedent to have an under-utilised panel.

Anyone any thoughts on this?

Last edited by Bloke (2016-11-26 15:52:10)

phiw13 · 2016-11-27 03:06:20

Based on the discussion above, two mockups (WIP/draft etc)

1. a grid, with the installed languages at the top.
2. a list, again with the installed languages at the top. Actually, I made it two lists here, one is the installed languages, the second one is the rest of the available languages (musing: one could then add a heading <h2> before each list for further clarity).

Bloke wrote #303008:

The more I look at it, the more I’m beginning to agree (sorry, Phil!)

I’m half here, half there. If a grid is well styled, finding a language should not be so difficult and has the advantage of a more compact display on larger screens. On the other hand, this is a little used panel, and a list-display is perhaps easier to scroll through.

One other thing to consider is non-privileged users. Do we need to show the installed languages at all? Is that information of use, considering they can’t do anything about it? Does the last updated date mean anything to them?

I think – in an ideal world – it is kinda friendly to show the list of installed languages (it is easier to scan through than the select drop down). Maybe even show the available languages, for an installation of Textpattern used in a really multi-lingual organisation. A user with low privileges might not be able to install the language, but, knowing it exist, might then check with the admin on duty to install it.

If we omit the entire list for those that have no need of it, the UI is a lot easier to build. But if they’re not getting the textarea for Textpacks and not getting any languages shown, and don’t have the ability to alter the front-side language, it makes the panel really sparse: just a single dropdown for their own admin-side language!

EDIT: Mind you, on the Users panel, non-privileged users get a single button to change their password, so it’s not without precedent to have an under-utilised panel.

A really minimal panel, no confusing possible, is quite likeable :-)

Textpattern CMS

Textpattern CMS support forum

#1 2016-03-02 10:19:57