...if the site's language and the language of the node being edited are different.

I noticed this when I set a css rule to hide the .active language link. All pages of the site were acting as supposed (only one language available for switching), but on node edit forms sometimes I'd see both of the site's available languages. I then saw that the li items were getting their lang-code and "first"/"last" classes, but none of them had the "active" class attached to it.

I guess this one is the opposite of #220559: Language switcher block highlights ALL languages as active ;)

Steps to reproduce:

1. Enable at least two languages for your site (say English and Italian).
2. Place the language switcher block to a region on your theme.
3. Enable translation for a content type (do not allow language neutral).
4. Create a node of that content type.
5. Translate the node to the other language.
6. View then go to the edit form of one of the node translations (say the Italian one).
7. While in the node edit form, switch the site's language to the other language (English in my example).
8. Check the classes of the language links...

This is easier to see if you have first used this css hack in your theme in order to hide the active language link from the language switcher:

ul.language-switcher-locale-url li.active {
  display: none;
}

Instead of only one flag/link in this case, you'll see both. One would expect that the site's current language link would be active (...thus have the .active class, thus be hidden from display).

Comments

jose reyero’s picture

Status: Active » Postponed (maintainer needs more info)

I don't think i18n modules are changing any link status so please make sure it is i18n.

Also as long as there's a core bug related to link status, maybe we should wait for that to be fixed first #220559: Language switcher block highlights ALL languages as active

klonos’s picture

Status: Postponed (maintainer needs more info) » Active

...please make sure it is i18n.

Please advise how. The only way I know of making sure a glitch is not a module's fault is to try disabling it and then checking if the glitch is still there. If I do this with i18n, I won't be able to reproduce the bug. Any ideas?

I agree that we should wait for the other related core bug to be fixed, but OTOH... a) the other issue is D6 while I notice this in 7.x only, b) the last three comments there date Oct 2009, Mar 2010, Mar 2011 :/

What do you thing?

klonos’s picture

PS: ...I thought of setting this issue to "postponed" as you suggest, but then again I do need your input. So feel free to postpone it if you cannot help me right now. ...plus I didn't want to leave it to "postponed, maintainer needs more info" because then it will eventually get auto-closed.

jose reyero’s picture

> The only way I know of making sure a glitch is not a module's fault is to try disabling it and then checking if the glitch is still there.
Right.
> If I do this with i18n, I won't be able to reproduce the bug.
Language switcher links are not produced by i18n.

jose reyero’s picture

Status: Active » Postponed (maintainer needs more info)

Don't worry, postponed issues don't get closed automatically.

I close them manually though if the requested information is not posted in a few days.

klonos’s picture

I thought there was some kind of "timer" set for postponed (MNMI) issues the same way way it is for fixed ones that are set to closed-fixed after 2 weeks of inactivity.

I think I need to try this in a vanilla setup ...give me a few days.

jose reyero’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Feel free to reopen when you are possitive it is an issue introduced by i18n.