By -Anti- on

Thought I'd ask here before reporting this as a 'language switcher' bug to be fixed in core.

1)
First a question, if I have installed the i18n module, does it replace the core language switcher block? If so, then this is a bug with the i18n language switcher, not the core one. I'd then also need to test the core one to see if it contains the same bug.

2)
Now the bug:

When viewing a node (eg. node/1) the language switcher class for the active language
(including the default if no language has been chosen) is: li en active
ie. the language code plus 'active'

The other languages listed (the non-active) have a class of: li es
ie. just their language code

This is great because then you can use css to show the user the selected language.
Eg. ul li.en a and ul li.en a.active

However, when viewing the front-page (ie. /node), the *all* languages listed in the
switcher block have a css class of: li [code] active.

I need to know if this is actually a bug, or whether I'm just not using the css correctly?
I also need to find out if the frontpage is the only url that does this?

Cheers.

⋅ Categories: Drupal 6.x

Comments

zeta ζ’s picture

zeta ζ commented

By li en active I assume you mean the tag li has the classes ‘en active’
By ul li.en a.active I assume you mean the css rule that selects an a tag with the class ‘active’ contained in an li tag with the class ‘en’ contained in a ul tag. Note this uses the active class from the a tag, not the li tag mentioned above.

The addition of the ‘active’ class is not done by the switcher at all – but by theme_links(), for the li tag – and by l() for the the a tag. This is decided based upon whether the destination of the link is the same as the current page.

The locale module (the part of core that switches language) produces links that all point to the current page (when you switch language, you don’t switch page); therefore they are all ‘active’.

The i18n module apparently produces links that seem to point to different pages; therefore only the link for the current language is ‘active’.

The ‘active’ class refers to the active link (the link that takes you to the current page), not the active language.

This does seem to be inconsistent, but in order to know what is a bug, you need to decide what is the ‘expected’ behaviour.
___________________
It’s in the detaιls…
demonstration portfolio

-Anti-’s picture

-Anti- commented

> The ‘active’ class refers to the active link (the link that takes you to the current page), not the active language.

Thanks for your reply.

I still don't understand why node/[N] will make just one of the language links 'active', whilst /forum /blog and /node make *all* of the language links 'active' even though there is only ever one language active at a time. For me this is very undesirable behaviour - it means that I cannot style the language switcher to show the user which language they currently have selected.

> The locale module (the part of core that switches language) produces links that all point to the current page (when you switch language, you don’t switch page); therefore they are all ‘active’.

But they don't, do they? /forum is not the same as /es/forum, is it?

Anyway...

1)
If the switcher can't do it, do you have any other ideas how I can clearly show the user what the currently selected language is?

2)
Do you know if I can get rid of the default language switcher, and use something else to choose languages?

Cheers!

zeta ζ’s picture

zeta ζ commented

/forum is not the same as /es/forum

But it points to the same page – just in a different language: So drupal removes the prefix, using it to control the language. Drupal can also use the domain for this, in which case the path is exactly the same, so removing the prefix makes this consistent.

To display the ‘active’ language in red; create a file called block-locale.tpl.php

  <div class="block block-<?php print $block->module; ?>" id="block-<?php print $block->module; ?>-<?php print $block->delta; ?>">
    <h2 class="title"><?php print $block->subject; ?></h2>
    <div class="content <?php global $language; print $language->language;?>">
      <?php print $block->content; ?>
    </div>
  </div>

This will add the language code to the div.content tag, so you can add the following to your css, with the language codes you use:

.block-locale .es .es,
.block-locale .en .en,
.block-locale .cy .cy,
.block-locale .fa .fa {
  color: red;
}

Alternatively; you could write a module that included a function phptemplate_translation_link_alter($links, $q) {which would be able to edit the links in the language switcher block.
___________________
It’s in the detaιls…
demonstration portfolio

-Anti-’s picture

-Anti- commented

Thanks for the time you spent writing that. It didn't work though, because the link itself is:

<li class="en first active">
<a class="language-link active" href="/test/node">English</a>
</li>

and the following is in system-menus.css (line 29), which over-rides your css due to the cascade:

li a.active { color:#000000; }

Don't go any further with this, Zeta - I've given up. The language switcher seems to be trying to do two or three different jobs, and failing at all of them. Other problems with it are:

· if a node isn't translated, the switcher doesn't use the alias, it uses node/[N]
· to edit a spanish node with an english interface, you have to manually delete the 'es' from the url
· if the node is 'language neutral' language links disappear from the switcher(!)

I can't work around them all. Not that I'm not grateful to the multilanguage team for doing all the work they've done so far (and to the i18n developers), but D6 was described as 'language ready', and its obviously nowhere near ready. My last cms had a half-assed implementation of language support, but it was still much more cohesive and functional than D6.

Anyway, I've given up trying to make it do anything sensible, so I'll just have to use it as it is and wait for D7.

Cheers.

zeta ζ’s picture

zeta ζ commented

it should give you the principle: Not working means I haven’t set up my test site with everything that you have, created test data and reproduced your scenario – then forgot about a detail :*) just add a or a.active to the end of each selector in the css rule I gave you; I think just a will work.

When reporting a bug, try to say what you expect to happen. The ‘failures’ you mention seem reasonable to me – I would need more details to assess them: If you complain about something, give up, then wait for D7 – you will find that D7 is very similar to D6 in regard to your complaint.

Instead, raise an issue for each detail you want to be different, having checked if any-one else is working on the same issue – say what you want instead, and your attempts to get it working. That way, D7 might stand a chance of working your way!
___________________
It’s in the detaιls…
demonstration portfolio

r.marino’s picture

r.marino commented

Hi,
i found the same problem. The front page marks all languages as active so I use this in page.tpl.php

<?php if (drupal_is_front_page()): ?>
<script type="text/javascript">
	$(document).ready(function() {
		$(".block-locale li").removeClass("active");
		$(".block-locale li.<?php global $language; print $language->language;?>").addClass("active");
		});
</script>
 <?php endif; ?>

It works for me.

Regards