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

CommentFileSizeAuthor
#2 views-config-translation-seven.png60.42 KBtstoeckler
#1 views-ui-config-translation.png63.14 KBtstoeckler
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
FileSize
views-ui-config-translation.png63.14 KB

Uploading screenshot in stark.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
Issue summary: View changes

Added screenshot in stark

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
FileSize
views-config-translation-seven.png60.42 KB

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

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
Issue tags: +Needs usability review

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

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
Issue summary: View changes

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

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
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

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

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

YesCT CreditAttribution: YesCT commented

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

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

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

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

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

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
Issue summary: View changes

Updated issue summary to include a second picture

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
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

vijaycs85
Location London, UK
CreditAttribution: vijaycs85 commented

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

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

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

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

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

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

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

Bojhan CreditAttribution: Bojhan commented

Mooore fieldsets!

vijaycs85’s picture

vijaycs85
Location London, UK
CreditAttribution: vijaycs85 as a volunteer and at Capgemini commented

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

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented
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

Bojhan CreditAttribution: Bojhan as a volunteer commented
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.

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.