Store Locator on two languages

This patch does this:

1) Adds a new setting on Google Store Locators administration page, in the form of a checkbox, with the title "Use enabled language for the map controls", which is described as:

If your site is multilingual (or use a language other than English as primary language) this will pass on the user's active language setting when requesting the map from google, translating various map controls.

2) If the setting is activated, it grabs the active user's language via the global $language and appends the ISO 3166 Alpha-2 country code with the "language" param to the maps.googleapis.com URL.

Note that this will ignore the users browser language setting and force the language the rest of your content is displayed in. You can read more about Google Maps localisation here.

Among the things left translating then, which is not possible to touch via Drupal's translation interface, is the 3 controls in the store bubble. Namely "Directions", "Zoom here" and "Street view". This would require overriding selectedStore_changed in JS, which seems to be a bit of a minefield in terms of private vars/methods. (The messages for "no stores" and "no stores in view" are also not working for the same reason. I'll submit a separate patch for that in a bug report.)

(cleaning up issue properties)

Was this patch commited to version 1? Applying the patch to v1 gave this message:

patching file google_store_locator.module
Hunk #1 FAILED at 136.
Hunk #2 succeeded at 254 (offset 16 lines).
Hunk #3 succeeded at 278 (offset 16 lines).
1 out of 3 hunks FAILED -- saving rejects to file google_store_locator.module.rej

Ok the patch refer to line 136 which has moved to line 170 instead. I copied-pasted the code and it works for me.

I'd say it's fair to assume one always wants the API in the language used by the CMS output.
Thus I don't think we need to make that configurable.
Attached a minimal approach that should apply to the latest dev.

@das-peter I disagree with that assumption. It's reasonable to think that there are cases where one could want to leave the language of a store locator up to the language set in the users browser. What my patch offers is an option to choose between this behavior (which is the existing/default) and forcing whatever language is active in Drupal. I think this is a more flexible solution that caters for a wider variety of sites / setups.

Let's say a site owner do not want the complexity of adding multi-lang support for their entire site, but would still like people to be able to find a store close to them even if the user do not speak the local language. They could leave the store locator to detect browser language, along with info in both the local language and english on that particular page for an example.

An alternative could be to flip things around, of course. To have the option I introduced enable browser-based language detection, and use Drupals language as default instead. The reason I chose to do it the way I did however, if I remember correctly, was that it would introduce the option without changing the behavior of sites already using the module (if they update their module further down the line).

I also agree with @hoesi, mostly because it is not recommended to change the behavior of sites already using this module. I know it one more option being added in admin screen, but maybe admin page could be reorganized in the future to group configurations to make it more user friendly for site administrators.

@hoesi, I did a review of your patch. Here is what I found:

1. variable_del() for gsl_lang_aware was not added in hook_uninstall()

2. +++ b/google_store_locator.module
   @@ -254,11 +262,17 @@ function theme_google_store_locator_contents($variables) {
   +  ¶
   

   Some additional spaces in blank lines are being added in this patch (there are 3 lines with this issue)

3. +++ b/google_store_locator.module
   @@ -254,11 +262,17 @@ function theme_google_store_locator_contents($variables) {
   +  if (variable_get('gsl_lang_aware', FALSE)){
   

   Missing space before brace "{"

Other than that, I think the patch is OK to be merged

Hi,
A patch update for the latest development version.

I have committed this patch to the dev branch with the option to enable and disable in the configuration page