Theme language switcher for seven theme

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?

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.

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

here again the broken screenshot:

This is first suggestion (UX improvements).

So, what you think?

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.

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

Also, why would you use lowercase at the start? Just to satisfy the general use of this dropdown link link? Languages are uppercase...

Ignore the characters case, It was quick "design in browser" thing.

Updated issue summary.

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

Maybe I can do it.
Just curious, do you consider to do it with:

• Default block for switching language, just put that block in some region and adjust css/theme
• Default block render in theme directly (without region), adjust css
• Create new theme function (or other custom coding) to render language links as dropbutton-widget

What are preferences here? This is what determines this task hard or easy.

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

I think this is the issue Gabor refers to: #1535868: 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.

Updated issue summary with issue summary template and remaining tasks.

Updated issue summary to add related issue: #1874102: Rename language switcher blocks (to differentiate content and UI)

Updated issue summary remaining tasks to help someone jump in to this.

I am going to work on this one. Going to create a language switcher block with drop button language list.

I'm working on this. Here are the options I can see:

• Add a new element (I'll call it a popbutton)
• Just CSS it
• Use the existing dropbutton element

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.

Now that I think about it, we could also extend the existing dropbutton. I think this is the way to go.

I dont know implementation details of how to do that, but extending the existing dropbutton *sounds* better to me.

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 list

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

Also it's possible that block should know the default language and make a sort inside

Not sure I get how to make default title for block, but it's title is not affected by the patch.

Just fixed tests

Configuring a block

Switch language (closed)

Switch language (open)

Here is block config patch. Now it is possible to configure how you want to show languages in the block

1. As a HTML list
2. As JavaScript operations

Adding #SprintWeekend tag

updating tags, looks a bit more reasonable (medium instead of challenging) with some specific things to fix.

also updating issue summary remaining tasks.

added related novice issue to retitle blocks

updated remaining tasks

Tagging to show on the frontend section of http://www.drupal8multilingual.org/

it's been a while. I think ok to unassign.
@Gaelan post to get back into it. :)

YesCT: That's fine. I should have done so earlier.

#22: 1498880-lang-22.patch queued for re-testing.

#30: 1498880-block-config-30.patch queued for re-testing.

Needs reroll

Rerolled #30 and run test.

Rerolled #30 and run test.

Rerolled #44

1. +++ b/core/modules/language/lib/Drupal/language/Plugin/Block/LanguageBlock.php
   @@ -73,6 +81,29 @@ function access(AccountInterface $account) {
   +
   +  /**
   +   * Overrides \Drupal\block\BlockBase::blockSubmit().
   +   */
   

   This should be {@inheritdoc}

2. +++ b/core/modules/language/lib/Drupal/language/Plugin/Block/LanguageBlock.php
   @@ -73,6 +81,29 @@ function access(AccountInterface $account) {
   +        'type' => t('JavaScript operations'),
   

   What about naming it "operations dropdown"? I had no idea what "Javascript operations" would be.

3. +++ b/core/modules/language/lib/Drupal/language/Plugin/Block/LanguageBlock.php
   @@ -89,6 +119,17 @@ public function build() {
   +      // Attach some logic.
   

   This comment is kinda pointless

4. +++ b/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   @@ -69,7 +69,7 @@ function testLanguageBlock() {
   +    foreach ($language_switcher_item as $link) {
   
   +++ b/core/modules/language/lib/Drupal/language/Plugin/Block/LanguageBlock.php
   @@ -89,6 +119,17 @@ public function build() {
   diff --git a/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php b/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   
   diff --git a/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php b/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   index 4613f43..1676f28 100644
   
   index 4613f43..1676f28 100644
   --- a/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   
   --- a/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   +++ b/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   
   +++ b/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   +++ b/core/modules/language/lib/Drupal/language/Tests/LanguageSwitchingTest.php
   @@ -60,7 +60,7 @@ function testLanguageBlock() {
   
   @@ -60,7 +60,7 @@ function testLanguageBlock() {
        $this->assertText($block->label(), 'Language switcher block found.');
    
        // Assert that only the current language is marked as active.
   -    list($language_switcher) = $this->xpath('//div[@id=:id]/div[contains(@class, "content")]', array(':id' => 'block-test-language-block'));
   +    $language_switcher_item = $this->xpath('//div[@id=:id]//li', array(':id' => 'block-test-language-block'));
        $links = array(
          'active' => array(),
          'inactive' => array(),
   @@ -69,7 +69,7 @@ function testLanguageBlock() {
   
   @@ -69,7 +69,7 @@ function testLanguageBlock() {
          'active' => array(),
          'inactive' => array(),
        );
   -    foreach ($language_switcher->ul->li as $link) {
   

   Should we also add some test coverage that the operations are rendered properly?

I'll take on this

Actions in #45 still needs to be completed, setting to Needs work and unassigning as no movement in 4 months.

I read all the lines of the patch. Looks good to me.
===
just a little clean up in the test:
removing double ..

using third person verb for function one line summary
"summary lines must start with a third person singular present tense verb, and they must explain what the function does. Example: "Calculates the maximum weight for a list." https://www.drupal.org/node/1354#functions

taking out an unused var ($block return value)

taking out a trailing whitespace

attaching interdiff (For instructions on creating an interdiff, see https://drupal.org/documentation/git/interdiff | Microbranching workflow: http://xjm.drupalgardens.com/blog/interdiffs-how-make-them-and-why-they-... )

manually tested.

Bartik

note #890362: Links should not be indicated by color only
and maybe #2271341: Drop button anchors easily broken by common theme styles
so that is not the problem of this issue.

Seven

==========

Needs work
a) for the super long select, (note this is both in bartik and seven) I think the width should just be the width of the longest language.

b) and also for #29: needs to show the current language, not always just the first one in the list (English)

#32 said

seriously needs more styling work as now the language switcher has no margins and looks sloppy on most seven pages.

But without a screenshot of that at the time, I'm not sure what it exactly might have needed done.

Reason for current language not going to first position is as far as I know that operation form element doesn't support #default_value parameter. We could rearrange the array somehow by hand to get the current language as first. I attached patch for an example.

reordering to put the current one first (in the operations like drop down) did work. but we should maybe only get the current language if we need to know it, so I put it inside the if.
----------

are we re-using the same input field as is used for other operations?
Our's is pushing down the stuff below it when opened, and other operations (like on the manage fields), go over other things, and do not push them down. See video: http://screencast.com/t/CdqUBaCKHnm4 (and outs is taking up the entire available width)

closed:

open (pushes stuff down)

a different operations input field that does not push stuff down, and instead overlays the next things is on the manage fields tab for node types.

This made me wonder how the languages are ordered anyway?
How should they be ordered?
Eventually, we want to show them in their localized/translated name, so Spanish would say Espanol (no matter what language the page was in). So... what order should they be? Because Alphabetical doesn't really make sense if each language name is in it's own language. I thought maybe they would be int he order they are ordered on the language config page, but they are not.

...
Anyway, other issues like #2239399: Languages should be sorted by label instead of title are having trouble with ordering languages. So let's just make the current language the one shown in the drop down (the default value or the first value), and more than that, we will not touch the ordering here.

back to needs work for the width of the drop-down

Sorry to bring this up now, I don't think the dropbutton is the correct element to use in this situation. The primary action in a dropbutton, the one that always shown, should do something. See 'edit' in the language listing table. What would the primary action do with the current implementation? I don't think it would do anything.

A more appropriate element would be a select element, the value that's always shown there is the default/current value, reading over the issue that is actually what Bojhan originally suggested

Dropbuttons and select elements do look similar, but they behave differently and have different use cases.

This must be outdated. I have been using the language switcher for testing issues for a few years now.