Part of meta #1836086: [meta] Entity Translation UI improvements

Problem/Motivation

After content translation module is enabled, there is this great page to configure translation settings of all content in one place. But the heading in the Admin/Configuration page doesn't reflect this -- it has nothing to do with translation. People miss it and go to each content type and field to turn translation on the hard way.

Proposed resolution

When the translation module is enabled, do an alter on the title. What we'd like to happen is:
(no translation module)
Content language
Configure language support for content

(with translation module)
Content language and translation
Configure language and translation support for content

Remaining tasks

Make a patch that changes the title/description for both cases (with and without the translation module enabled) so they are consistent and clear.

User interface changes

Change in title/description on admin/config.

API changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kalabro’s picture

Assigned: Unassigned » kalabro

#CodeSprintUA 2013 Online team will work on it today.

kalabro’s picture

Status: Active » Needs review
Issue tags: +CodeSprintUA
FileSize
497 bytes
24.86 KB

Looks like "Content language and translation settings" is too long for menu link name.
I suggest to ommit "settings" word.

Screenshot with result:
2013-06-02_14-15-20.png

ddrozdik’s picture

kalabro, I think this is not a good idea to change title of page in the hook_menu_alter, the best way to do this in the hook_menu() in the language module.
Attached patch with changes into the language module

alphawebgroup’s picture

Status: Needs review » Reviewed & tested by the community

looks good as for me.
applied [2004878-3] patch, works good

andypost’s picture

Status: Reviewed & tested by the community » Needs review

#3 is wrong, title should not be changed before translation_entity module enabled

YesCT’s picture

Assigned: kalabro » YesCT
Status: Needs review » Needs work
FileSize
195.06 KB
184.57 KB
190.83 KB
197.97 KB

here are screenshots from patch in #2

before enable language module

before-languages.png

after enable language module

after-enable-language.png

after enable interface translation module

after-enable-interface-translation.png

after enable content translation module

after-enable-content-translation.png

----
I think we need to keep "settings" because this is not where to go to do translation. it's for translation settings.
Let's try it with the settings and see how bad it is to have a long name.

patch coming.

YesCT’s picture

Status: Needs work » Needs review
FileSize
739 bytes
650 bytes
218.44 KB
220.3 KB

Do we need to alter the description also?

before

before-patch-sidebar.png

after

after-patch-sidebar.png

patch adds a comment, and uses settings word back.

YesCT’s picture

Assigned: YesCT » Unassigned
andypost’s picture

Suppose "multilingual element" makes no sense as description for the functionality as whole

Gábor Hojtsy’s picture

The element word seems to work around that we cannot say "entity" on the public UI.

Gábor Hojtsy’s picture

The element word seems to work around that we cannot say "entity" on the public UI.

podarok’s picture

Status: Needs review » Active

Something wrong with bot
Queue - clean, but patch here - queued
triggering

podarok’s picture

yet one try

robertdbailey’s picture

Status: Active » Reviewed & tested by the community
FileSize
21.06 KB
20.72 KB

This change appears to satisfy the requirement. After enabling Languages module but before enabling Content Translation:
Selection_001.png

After enabling both the Languages module and the Content Translation module:
Selection_002.png

jhodgdon’s picture

Status: Reviewed & tested by the community » Needs work

What exactly is a "multilingual element"? I have no idea what that means.

Should the description just say "Configure language support for content" and then "Configure language and translation support for content" after the content translation module is enabled? That seems like it would make more sense...

Gábor Hojtsy’s picture

@jhodgdon: what we are struggling with here is that Content (node) is a type of Content (entity). This page applies to Content (entities) in general not just Content (nodes). We wanted to somehow express that this does not only apply to Content only but Content in general.

jhodgdon’s picture

You mean that "multilingual element" is supposed to mean "any translatable content entity"? Substituting one incomprehensible term (multilingual element) for another (entity, which is only understandable by Drupal programmers) is not really helpful, in my opinion. Do you think people know what "multilingual element" means? I didn't, and actually, I still don't know what entities have language features... Which ones do?

So... The root of this problem is that we had this module that "someone" called "Node" way back at the beginning of Drupal, and in Drupal 7, we determined no one understood "node" and it was bad for usability, and "nodes" were renamed "content items" for the UI. However, we now are coming to the realization that Nodes are just one type of content on a site (there are also comments, blocks, fields on user accounts, etc.). Right?

So we invented the programming term "entity" to encompass all of that... and now we need to come up with an understandable non-programming, non-jargon term that means "All the content on the site that can be translated", and make that distinct from "the content items that the Node module manages".

Right?

This seems like a bigger UI issue... but please let's not use "multilingual element" as the all-encompassing term. I really still have no idea what it means.

Gábor Hojtsy’s picture

@jhodgon: indeed "multilingual element" in this description seems to refer to "configurable fields and non-configurable fields (properties) on any *content* entity which may have language support". What appears on this config page depends on what kinds of content entities do your site have (modules can provide numerous), if those content entities support having language variance (eg. menus are still not supporting this in core but are being worked on). Then those entities may have translatable properties and configurable fields. I'm fine leaving that out if you think "Content" is sufficiently descriptive to express the depth of this screen not only applying to nodes on the highest level only.

One of the problems with terminology is if you go to this page, you get a list of checkboxes where one of them is "content" (see https://drupal.org/node/2004878#comment-7487822 above). So on the content language setup page, you can configure language for content AND other things (that are also content) :D

jhodgdon’s picture

My feeling is that "content" is the correct generic term -- I was never thrilled with the idea of calling Nodes "content items", because there is a lot of other content on your average site that isn't nodes.

So really, maybe what is needed is a better term for Nodes, like "generic standard content thingies", perhaps? :)

YesCT’s picture

Issue tags: +Novice

ok, now that we have decided. lets change the description too,
the default one without the translation module enabled.
bonus for adding translation to that description when content translation is enabled.

kalabro’s picture

So, do I understand correctly?

1. Content language settings
Configure language support for content

2. Content language and translation
Configure language and translation support for content

Gábor Hojtsy’s picture

@kalabro: that seems to be the direction, yes. I think at this point the description is not really clarifying anything, so we only provide it for the sake of being provided for a unified look of this screen. Its not better explanatory than the title. (Which was arguably true for the text before the patch too :D)

jair’s picture

Issue tags: +Needs reroll
yoroy’s picture

Issue tags: -Needs usability review

Proposal in #21 looks good to me although the description for 2. adds very little extra information.

jhodgdon’s picture

Also the proposal in #21 has removed the word "settings" from the heading, which (see discussion above) U think we still need (even if it does make the title long). You can't do translations at that page -- it is just the settings for content translation, not the page to *do* translation.

yoroy’s picture

Well, "evertyhing" on configuration page is about settings right? Most of the items on the configuration page are not about *doing the thing* but about *settings for doing the thing*, so I think we can leave it out.

jhodgdon’s picture

Good point in #26. So then let's make the two headings consistent:

1. Content language
Configure language support for content

2. Content language and translation
Configure language and translation support for content

Gábor Hojtsy’s picture

Sounds great to me @jhodgdon!

jhodgdon’s picture

Issue tags: -Needs reroll

I just updated the issue summary with our current plan.

I think that making a patch for this would be a fine Novice issue (or one of the previous participants could jump in and make a new patch. The patch in #7 illustrates how to alter the title when the translation module is enabled (we need to alter both title and description though I think), and the patch in #3 illustrates how to change the base title (we need to update both title and description though I think). So some combination should do it -- should be about a 4-line patch.

Oh, I see it's already marked Novice. Let's get a patch please!

kalabro’s picture

Assigned: Unassigned » kalabro
kalabro’s picture

Assigned: kalabro » Unassigned
Status: Needs work » Needs review
FileSize
2.11 KB
31.5 KB
28.62 KB

“Language” enabled, “Content Translation” disabled:
2013-10-02_15-55-24.png

“Content Translation” enabled:
2013-10-02_16-02-52.png

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me based on above discussion.

jhodgdon’s picture

I concur -- thanks for the patch kalabro!

Gábor Hojtsy’s picture

Issue tags: +sprint, +language-content

Tag on sprint for easier tracking.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Looks good. Committed/pushed to 8.x, thanks!

Gábor Hojtsy’s picture

Issue tags: -sprint

Superb, thanks!

Status: Fixed » Closed (fixed)
Issue tags: -Usability, -Novice, -D8MI, -language-content, -CodeSprintUA

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

updated summary with current plan

klonos’s picture

Issue summary: View changes
Issue tags: +Usability, +Novice, +D8MI, +language-content, +CodeSprintUA

...adding back tags eaten by the tag monster.