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.

Files: 

Comments

Assigned:Unassigned» kalabro

#CodeSprintUA 2013 Online team will work on it today.

Status:Active» Needs review
Issue tags:+CodeSprintUA
StatusFileSize
new497 bytes
PASSED: [[SimpleTest]]: [MySQL] 55,845 pass(es).
[ View ]
new24.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

StatusFileSize
new655 bytes
PASSED: [[SimpleTest]]: [MySQL] 55,859 pass(es).
[ View ]

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

Status:Needs review» Reviewed & tested by the community

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

Status:Reviewed & tested by the community» Needs review

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

Assigned:kalabro» YesCT
Status:Needs review» Needs work
StatusFileSize
new195.06 KB
new184.57 KB
new190.83 KB
new197.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.

Status:Needs work» Needs review
StatusFileSize
new739 bytes
new650 bytes
PASSED: [[SimpleTest]]: [MySQL] 55,631 pass(es).
[ View ]
new218.44 KB
new220.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.

Assigned:YesCT» Unassigned

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

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

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

Status:Needs review» Active

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

yet one try

Status:Active» Reviewed & tested by the community
StatusFileSize
new21.06 KB
new20.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

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...

@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.

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.

@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

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

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.

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

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

Issue tags:+Needs reroll

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

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.

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.

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

Sounds great to me @jhodgdon!

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!

Assigned:Unassigned» kalabro

Assigned:kalabro» Unassigned
Status:Needs work» Needs review
StatusFileSize
new2.11 KB
PASSED: [[SimpleTest]]: [MySQL] 58,329 pass(es).
[ View ]
new31.5 KB
new28.62 KB

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

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

Status:Needs review» Reviewed & tested by the community

Looks good to me based on above discussion.

I concur -- thanks for the patch kalabro!

Issue tags:+sprint, +language-content

Tag on sprint for easier tracking.

Status:Reviewed & tested by the community» Fixed

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

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.

Issue summary:View changes

updated summary with current plan

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

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