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.
Comment | File | Size | Author |
---|---|---|---|
#31 | 2004878-config_page_title_for_content_language-31.patch | 2.11 KB | kalabro |
#14 | Selection_001.png | 20.72 KB | robertdbailey |
#14 | Selection_002.png | 21.06 KB | robertdbailey |
#7 | before-patch-sidebar.png | 220.3 KB | YesCT |
#7 | after-patch-sidebar.png | 218.44 KB | YesCT |
Comments
Comment #1
kalabro#CodeSprintUA 2013 Online team will work on it today.
Comment #2
kalabroLooks like "Content language and translation settings" is too long for menu link name.
I suggest to ommit "settings" word.
Screenshot with result:
Comment #3
ddrozdik CreditAttribution: ddrozdik commentedkalabro, 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
Comment #4
alphawebgrouplooks good as for me.
applied [2004878-3] patch, works good
Comment #5
andypost#3 is wrong, title should not be changed before translation_entity module enabled
Comment #6
YesCT CreditAttribution: YesCT commentedhere are screenshots from patch in #2
before enable language module
after enable language module
after enable interface translation module
after enable content translation module
----
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.
Comment #7
YesCT CreditAttribution: YesCT commentedDo we need to alter the description also?
before
after
patch adds a comment, and uses settings word back.
Comment #8
YesCT CreditAttribution: YesCT commentedComment #9
andypostSuppose "multilingual element" makes no sense as description for the functionality as whole
Comment #10
Gábor HojtsyThe element word seems to work around that we cannot say "entity" on the public UI.
Comment #11
Gábor HojtsyThe element word seems to work around that we cannot say "entity" on the public UI.
Comment #12
podarokSomething wrong with bot
Queue - clean, but patch here - queued
triggering
Comment #13
podarokyet one try
Comment #14
robertdbailey CreditAttribution: robertdbailey commentedThis change appears to satisfy the requirement. After enabling Languages module but before enabling Content Translation:
After enabling both the Languages module and the Content Translation module:
Comment #15
jhodgdonWhat 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...
Comment #16
Gábor Hojtsy@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.
Comment #17
jhodgdonYou 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.
Comment #18
Gábor Hojtsy@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
Comment #19
jhodgdonMy 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? :)
Comment #20
YesCT CreditAttribution: YesCT commentedok, 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.
Comment #21
kalabroSo, 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
Comment #22
Gábor Hojtsy@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)
Comment #23
jair CreditAttribution: jair commentedComment #24
yoroy CreditAttribution: yoroy commentedProposal in #21 looks good to me although the description for 2. adds very little extra information.
Comment #25
jhodgdonAlso 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.
Comment #26
yoroy CreditAttribution: yoroy commentedWell, "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.
Comment #27
jhodgdonGood 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
Comment #28
Gábor HojtsySounds great to me @jhodgdon!
Comment #29
jhodgdonI 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!
Comment #30
kalabroComment #31
kalabro“Language” enabled, “Content Translation” disabled:
“Content Translation” enabled:
Comment #32
Gábor HojtsyLooks good to me based on above discussion.
Comment #33
jhodgdonI concur -- thanks for the patch kalabro!
Comment #34
Gábor HojtsyTag on sprint for easier tracking.
Comment #35
catchLooks good. Committed/pushed to 8.x, thanks!
Comment #36
Gábor HojtsySuperb, thanks!
Comment #37.0
(not verified) CreditAttribution: commentedupdated summary with current plan
Comment #38
klonos...adding back tags eaten by the tag monster.