Language choice by authors into the "Authors" page.

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 :-)

Bloke · 2016-11-27 09:26:50

phiw13 wrote #303010:

a grid, with the installed languages at the top.

I like the look of that. Clear status of each language. Clear calls to action. And it’s fairly easy to find uninstalled languages (I think I was just tired when I looked the other day, or had forgotten my alphabet or something), and is a good use of space. Great stuff.

it is kinda friendly to show the list of installed languages… 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.

That’s a good point. Assuming we adopt some version of your grid-based view above, non-privileged users would see an identical layout, but simply omitting the buttons. Even having the status line and last update date is handy info because, as you say, an astute user can nudge an admin to take action.

One slight wrinkle is that, under the “bundle language packs in core” model we’re planning, the notion of ‘update available’ is thorny. Without using the RPC server or some other machine-readable index, client sites won’t actually know there’s an update available. The only time the interface knows will be if the admin has downloaded a new pack, dropped it in the lang directory, and the file’s last mod indicator (either the file date stamp itself, or — more likely — some version/date string on the first line as we have now) is different from what’s in the database.

Phil is intending to maintain a (live? live-ish?) translation page on the .com site. I’ve misplaced the link to the mockup. That will serve as:

an advertisement: “look how many languages Textpattern is available in”.
a record of the current translation effort as a natty progress bar/percentage indicator: “your language is under-represented, please help make it better”.
a place to download packs so they can be uploaded to your site and then installed from the Languages panel. Presumably, some kind of freshness indicator on the site would be prudent here.

If we receive a glut of translations at any time between releases, we’ll issue a point release so that translations are automatically rolled into core for those that upgrade. In the (smaller) time interval between releases, the packs will be manually downloadable/installable by admins.

Now, there’s nothing to stop us adding a link on the Languages panel to that page so anyone can see the current status. Might as well make it easy for any user to see the current status (though quite where we’d put that on the Languages panel is unclear to me). Regardless, the only planned difference to the current system is that you won’t see an ‘update available’ message or ‘update’ button unless the Textpack file is different. And that’s proposed as a manual process from now on, rather than a ‘ping some server to find out’ thing.

None of this changes the way the panel is laid out, or how calls to action are offered, it’s just a subtle shift in approach to avoid reliance on (or overloading) some third party site.

wet · 2016-12-02 09:05:40

Bloke wrote #303008:

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

What Stef says.

philwareham · 2016-12-02 09:42:28

Bit late to this thread.

I’m still not keen on the list view, sorry. The grid (with additional improvements as suggested by Philippe) makes much better use of space, and to my eyes is easier to scan.

Regarding the language translations page, a rough mockup is here although it needs work and some extra functionality. The update button on languages in admin panel would only be available if you’ve downloaded an updated Textpack and put it into the `lang` directory (or wherever we put language packs in 4.7).

Bloke · 2016-12-02 09:56:03

I’m down with the grid view if it’s presented in a Philippe-style manner and is easy to visually scan :-)

I can look into pulling installed languages to the head of the grid if that’s of more use to people, or we could hide uninstalled languages unless some ‘show all’ is checked (or something).

I’m easy either way.

philwareham · 2016-12-02 09:59:53

Bloke wrote #303119:

I can look into pulling installed languages to the head of the grid if that’s of more use to people, or we could hide uninstalled languages unless some ‘show all’ is checked (or something).

My vote: Installed languages at top, always show everything.

Bloke · 2016-12-02 10:24:31

philwareham wrote #303120:

My vote: Installed languages at top, always show everything.

Cool. I’ll see what I can do. Can you rejig your mockup to take Philippe’s ideas into consideration please, then I’ll get it done.

philwareham · 2016-12-02 10:38:51

Bloke wrote #303121:

Cool. I’ll see what I can do. Can you rejig your mockup to take Philippe’s ideas into consideration please, then I’ll get it done.

Done – you might need to refresh cache to see changes.

Pat64 · 2016-12-14 13:58:50

“Dashboard in your language”

Following the excellent and efficient work by Stef, WordPress latest version use now a per-user language for its admin interface :D

Pat64 wrote #303257:

Following the excellent and efficient work by Stef, WordPress latest version use now a per-user language for its admin interface

Hehehe, I’m such a trendsetter! :-)

In reality, it makes a change to be ahead of the big boys with something. Normally we’re ten years behind…

Textpattern CMS

Textpattern CMS support forum

#13 2016-11-26 14:10:57

Re: Language choice by authors into the "Authors" page.

#14 2016-11-26 15:50:24

Re: Language choice by authors into the "Authors" page.

jakob wrote #303007:

#15 2016-11-27 03:06:20

Re: Language choice by authors into the "Authors" page.

Bloke wrote #303008:

#16 2016-11-27 09:26:50

Re: Language choice by authors into the "Authors" page.

phiw13 wrote #303010:

#17 2016-12-02 09:05:40

Re: Language choice by authors into the "Authors" page.

Bloke wrote #303008:

#18 2016-12-02 09:42:28

Re: Language choice by authors into the "Authors" page.

#19 2016-12-02 09:56:03

Re: Language choice by authors into the "Authors" page.

#20 2016-12-02 09:59:53

Re: Language choice by authors into the "Authors" page.

Bloke wrote #303119:

#21 2016-12-02 10:24:31

Re: Language choice by authors into the "Authors" page.

philwareham wrote #303120:

#22 2016-12-02 10:38:51

Re: Language choice by authors into the "Authors" page.

Bloke wrote #303121:

#23 2016-12-14 13:58:50

Re: Language choice by authors into the "Authors" page.

#24 2016-12-14 15:13:58

Re: Language choice by authors into the "Authors" page.

Pat64 wrote #303257:

Board footer