| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | language.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | #SprintWeekend, D8MI, frontend, language-config, language-content, medium, Usability |
Issue Summary
Problem/Motivation
With the introduction of the form language concept in #1498874: Provide language awareness to entity forms (introduce the form language concept), we will need a language switcher allowing to choose the form active language.
Proposed resolution
Agreement that a drop button as in #7
Remaining tasks
Done: mock ups.
Done: ui element chosen. (We need to figure out if this can be a regular language switcher block or if it will be a UI elelment placed inside the form itself.)
Done: initial implementation (proceeded since form language landed #1498874: Provide language awareness to entity forms (introduce the form language concept)).
Todo:
- refine according to feedback in #32. Contributor Task to create patch: http://drupal.org/node/1424598
- (waiting on refinement) manually test, after implementation. Contributor Task to manually test: http://drupal.org/node/1489010 (be sure to note browsers used)
- final screenshots, after implementation
User interface changes
API changes
todo: clarify if there would be api changes. (API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate)
Related
#1874102: Rename language switcher blocks (to differentiate content and UI)
Comments
#1
tagging
#2
So I guess #1498874: Provide language awareness to entity forms (introduce the form language concept) should go first? :) Or would you like to get people going with making up ideas about this?
#3
Well, surely some UX discussion could help here. However the implementation will have to wait for form language to land...
#4
Retitling issue for updated thinking, that it should just be the language switcher block reused. Needs to be themed for Seven since it looks bad as-is.
#5
i would work on this,
right now there is a list displayed, what would you imagine instead .. ?
there are also a lot of modules around that block. (dropdown, flags etc.)
could be some show/hide functionality for the list, useful if very big ..
also there are two blocks now (UI text / content) - probably they should have a different feeling
#6
here again the broken screenshot:
#7
This is first suggestion (UX improvements).
So, what you think?
#8
i like the approach; reuse of the standard - dropbutton (at least looks like it) - this will even be cross-theme !
maybe the title could be placed before, inlined.
#9
Wow, it is amazingly fascinating how close is this to Bojhan's suggestion from http://drupal.org/node/1282018#comment-6120798, amazing. Will let him know to look at this one :)
#10
Also, why would you use lowercase at the start? Just to satisfy the general use of this dropdown link link? Languages are uppercase...
#11
Ignore the characters case, It was quick "design in browser" thing.
#12
Good. Drop button seems to be the right way to go here, since the action of switching will be done right on picking (there is no additional save or switch button).
I'll update the issue summary.
If someone wants to code this up, go ahead and assign the issue to yourself. :) [edit: @plach do you think this could be picked up by someone? I am not sure what level of difficulty it is but it seemed like it might be not too hard for someone to come into.]
#13
Maybe I can do it.
Just curious, do you consider to do it with:
What are preferences here? This is what determines this task hard or easy.
#14
@Dragan Eror: I'd add a theme function override for the language list in the Seven theme (it does not currently have its own theme I think although it might in fact have). If/when blocks as plugins are committed, we could have instance settings on blocks, so we can set a block instance in the frontend theme to be a classic HTML list display and on the backend as a dropbutton.
#15
I think this is the issue Gabor refers to: #1535868: Change notice: Convert all blocks into plugins
We could get a start on this without worrying about that, or use one of the recent patches there, and do something on top of that.
I'm guessing this is a good issue for someone to jump into, but that it might be challenging (not novice).
The desired UI is agreed on, any initial patch is good at spurring on progress.
I'll update the issue summary remaining tasks.
#16
Updated issue summary to add related issue: #1874102: Rename language switcher blocks (to differentiate content and UI)
#17
I am going to work on this one. Going to create a language switcher block with drop button language list.
#18
I'm working on this. Here are the options I can see:
I personally prefer the popbutton element because I think we need CSS, and I think the dropbutton is meant for "you haven't selected any of these options, select one now", instead of "this is your current option, you can switch to a new one if you want." Going to start on the popbutton.
#19
Now that I think about it, we could also extend the existing dropbutton. I think this is the way to go.
#20
I dont know implementation details of how to do that, but extending the existing dropbutton *sounds* better to me.
#21
Currently the language switcher is output as plain links, we should either alter them only for seven or have a dropbutton also in the default theme. Not sure this would be a good choice. Again a word from @Bojhan would be welcome.
#22
Here's a simple patch and screenshot.
The main problem that active item by default does not show active language, suppose
language_negotiation_get_switch_links()needs to be modified to order the listAnother issue that default block title is too big and probably we need to ship 2 css files to make this block float (rtl second one)
#23
Also it's possible that block should know the default language and make a sort inside
#24
The last submitted patch, 1498880-lang-22.patch, failed testing.
#25
In #1874102: Rename language switcher blocks (to differentiate content and UI) we agreed about going for a just "Language" as title, if only one configurable langauge is enabled. This will probably happen in #1833022: Only display interface language detection options to customize more granularity .
#26
Not sure I get how to make default title for block, but it's title is not affected by the patch.
Just fixed tests
#27
Can we get a screenshot of the language switcher in Bartik?
#28
Configuring a block
Switch language (closed)
Switch language (open)
#29
Thanks, looks acceptable to me in Bartik too. As you were saying we probably need to change the order of links so that the current one is always first, i.e. the visible one.
#30
Here is block config patch. Now it is possible to configure how you want to show languages in the block
#31
Adding #SprintWeekend tag
#32
Functionally the patch looks good to me, but it seriously needs more styling work as now the language switcher has no margins and looks sloppy on most seven pages. We could consider floating the language switcher on the right to match Bojhan's proposal: #1282018-99: Improve UX of language-aware entity forms.
+++ b/core/modules/language/lib/Drupal/language/Plugin/block/block/LanguageBlock.php@@ -31,6 +40,29 @@ function blockAccess() {
+ 'theme' => t('HTML List'),
+ 'type' => t('JavaScript operations'),
These labels do not look very user-friendly to me. What about:
+++ b/core/modules/language/lib/Drupal/language/Plugin/block/block/LanguageBlock.php@@ -49,6 +80,17 @@ public function build() {
+ // Attach some logic.
This comment is not very informative.
#33
updating tags, looks a bit more reasonable (medium instead of challenging) with some specific things to fix.
also updating issue summary remaining tasks.
#34
Tagging to show on the frontend section of http://www.drupal8multilingual.org/
#35
it's been a while. I think ok to unassign.
@Gaelan post to get back into it. :)
#36
YesCT: That's fine. I should have done so earlier.
#37
#22: 1498880-lang-22.patch queued for re-testing.
#38
#30: 1498880-block-config-30.patch queued for re-testing.
#39
The last submitted patch, 1498880-block-config-30.patch, failed testing.