I just translated a view for fun and it is a pretty massive form. I think we should get some usability people to look at this and discuss this upfront. I don't think anyone is trying to argue that this is actually a nice form, the question is just whether we can make it any better.

To test this yourself use this link on simplytest.me:
http://simplytest.me/project/drupal/8.x?patch[]=https://drupal.org/files...
* Don't use English as the install language, but a different one. This saves you from having to add a language manually.
* Enable "Configuration Translation" module.
* Go to the frontpage. The frontpage view should now have a "Translate view" contextual link (If this instruction confuses you, do the following: Click the pencil in the very top right corner of the screen. Now click the pencil that showed up to the right of the " Welcome to s4c5af6124797fd2.s3.simplytest.me " site name. You should now see a "Translate view" link.)
* Click the translate view link
* You should see a list of two languages: English, and the one you installed in. Click the Edit link for the not-English one.
* You should now see a sea of nested details :-)

Comments

tstoeckler’s picture

Uploading screenshot in stark.

tstoeckler’s picture

Issue summary: View changes

Added screenshot in stark

tstoeckler’s picture

Another screenshot from simplytest.me

Tagging "Needs usability review" for some usability folks to spot this, maybe. I hope my instructions in the issue summary are understandable, otherwise please just say so, and I will try harder :-)

tstoeckler’s picture

Issue tags: +Needs usability review

Not the tag monster, but the sleep deprivation monster...

tstoeckler’s picture

Issue summary: View changes

Updated issue summary to include steps to get to the form on simplytest.me

Gábor Hojtsy’s picture

Issue tags: +D8MI, +language-config

Yeah, well, views is an extreme :D Not sure myself how to cater for that outside of adding a specific translation interface tailored for that... I think these are the questions where getting this into core and having eyes on it would be really helpful.

tstoeckler’s picture

Yes, I totally agree. With this issue I'm just trying to avoid a situation where the core issue is finally RTBC and then e.g. Bojhan understandably freaks out. So I think we need to communicate the constraints we have very clearly, and also get some early feedback if there maybe *is* something that we can do better.

YesCT’s picture

1. in stark, the label and the value run together, can we separate them?

2. some say (empty) in the collapsable group,
is that to help people, so they do not open it up?
because it might be misleading, for example the stark img shows the 'next page link text' which has a value, but it is burried under another (empty) heading, default display options

Gábor Hojtsy’s picture

No, (empty) is the bubbling up of the (empty) label of the value underneath. The same where it says "Master Display settings", the "Master" bubbles up from the title, because the display settings are for the display titled "Master".

tstoeckler’s picture

1. I've thought about this too, but this is just theme_item () so could be a separate core issue then.

tstoeckler’s picture

Issue summary: View changes

Updated issue summary to include a second picture

Gábor Hojtsy’s picture

Title: UI review of the auto-generated translate forms » Design and build dedicated translation form for views
Project: (Obsolete) configuration translation for Drupal 8 » Drupal core
Version: 8.x-1.x-dev » 8.x-dev
Component: User interface » config_translation.module
Issue summary: View changes
Issue tags: +Usability, +Needs issue summary update

As per #1952394-192: Add configuration translation user interface module in core and following comments, refocusing this on the views translation UI itself. Now needs issue summary update.

vijaycs85’s picture

Planning to try this as a contrib module (https://drupal.org/sandbox/vijaycs85/2137779).

Gábor Hojtsy’s picture

When this gets into core, I don't think this should be a separate module **in core**, it should be a separate interface class or some other one-off implementation for views (unless we figure out a generic pattern that may apply to other complex config entities).

tstoeckler’s picture

So in the end the form we generate is just another way to display a form for an entity, in this case for a view.

My thought process was the following: For configuration forms we leave everything as is, but for config entities we introduce another form controller 'translation' or whatever, that defaults to the auto-generated form. Views (UI?) module then specifies a separate translation form controller which provides the custom-tailored form.

Thoughts?

Gábor Hojtsy’s picture

Still needs issue summary update. Here is the note from @webchick from [#8185179-192]:

We should maybe discuss what to do with this screen a bit more. At a glance, it looks like I can only translate two things: Administrative description and Human readable name. But there are literally hundreds of other things, getting to most of them requires clicking into the various collapsed field sets/details. And getting to each one requires click to expand, fill out a bit, click to expand, fill out a bit, etc. which makes what is already a daunting task feel even worse.

TL;DR: Should we auto-expand all of these fieldsets/details by default? Particularly if the English and XXX language versions still match?

Bojhan’s picture

Mooore fieldsets!

vijaycs85’s picture

I don't think we are going to make this part of 8.0.0. I created a sandbox to try this at https://www.drupal.org/sandbox/vijaycs85/2137779 but never managed to work on it. May be this one need to stay on contrib for now?

If agreed, we can make this "Won't fix" and close it.

Gábor Hojtsy’s picture

Version: 8.0.x-dev » 8.1.x-dev

Moving to 8.1.x. Closing as won't fix would indicate that we don't care about the problem even as much as to sometime fix it in the future, right? If we consider this not a usability fail but a usability improvement to make, then 8.1.x is the right version. (If usability fail, then it should stay as 8.0.x.).

Bojhan’s picture

Issue tags: -Needs usability review

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.