Use path prefix/domain for determining language as opposed to rewriting URLs [#2118365]

Problem/Motivation

Using both the cookie and the URL provider at the same time does not seem to work properly, and an unnecessary language=XX query string is appended to all links.

Proposed resolution

If we already use the URL (path or domain) provider, it should not be needed to rewrite the URLs, or to modify the language switcher.

Remaining tasks

User interface changes

API changes

Currently, Drupal core loads the providers for the URL language type (ie. language used to render all links in a page / default language for url()) in this order:

locale-url (The language is determined using a URL language indicator: path prefix or domain according to the configuration.)
locale-url-fallback ( If no URL language is available language is determined using an already detected one.)

The attached patch changes this to:

locale-url
language_cookie (gets the language from the cookie that has been set)
locale-url-fallback (if no cookie set, use default language)

Additionally, if the URL provider is enabled in the "language detection and selection" settings page, this willl mean:

No more URL rewrites, so no more ?language=XX appended to links.
No more cookie language switcher, so no more cookie-active, session-active, language-link classes on the language selector.

Comment	File	Size	Author
#1	language_cookie.url-cookie-provider.2118365-1.patch	2.88 KB	stefan.r
	language_cookie.cookie-url-provider.patch	2.59 KB	stefan.r

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

stefan.r CreditAttribution: stefan.r commented 23 October 2013 at 10:14

File	Size
language_cookie.url-cookie-provider.2118365-1.patch	2.88 KB

Upon testing with the user "Babou" on a clean install it looks like the patch needed to have a "types" array in the negotiation info array. An update hook such as this may also be useful to refresh the providers for the URL language type if anyone had it already enabled:

function language_cookie_update_7200() {
  language_types_set();
}

Comment #2

stefan.r CreditAttribution: stefan.r commented 23 October 2013 at 09:49

Assigned:	Unassigned	» stefan.r
Status:	Active	» Needs review

To clarify, if you pick your Language Detection and Selection providers in this order in the admin control panel:

1. URL
2. Cookie
3. Default

It will first attempt to find the language from the URL (path prefix or domain). If it finds a language there, that's the language we'll use. If no language is found (ie. there is no specific domain/path prefix where we can find out what language a page should be in), it will look for the language cookie set by this module. If no cookie had been set, it will display the page in the default language.

Comment #3

Babou CreditAttribution: Babou commented 23 October 2013 at 09:54

We tested this with our distribution and it seems to work.

Comment #4

alexweber CreditAttribution: alexweber commented 23 October 2013 at 13:14

The fix looks pretty good to me, are there any caveats? Can upgrading break anything?

Comment #5

stefan.r CreditAttribution: stefan.r commented 23 October 2013 at 14:58

Nope, shouldn't break anything, though to be fair it is a big rewrite compared to the current behavior so perhaps a beta release is in order :)

Comment #6

alexweber CreditAttribution: alexweber commented 23 October 2013 at 16:01

@stefan, can we test an upgrade maybe? Make sure settings don't break?

I think in our case, given the number of users we have, a beta is no different than a full release... the few people who use this will probably download it anyway so we can just call it a new version... if it's really *that* major man maybe we can release an unsupported 2.0-beta-1 version for example, that's an idea i like more.

lmk your thoughts!