Multilingual support for "Where are you?" and filter labels

So I have the same problem. If you have a solution, please tell me.

Probably best to follow this instructions https://www.drupal.org/node/1835940

"Where are you?" and filter labels are not placeholders so instructions in #2 don't apply.

Patch attached. The strings need to be translatable with t(). Once translatable (and encountered in a non-default language) the strings will appear in the translate interface and translations will work.

I think a better solution would be integrating with i18n module (https://www.drupal.org/project/i18n)
A how-to is available here: https://www.drupal.org/node/1113374

Also, because the string is "dynamic" (it can be changed in admin interface), the function t() is not the best solution, because if the English version is changed, you will have to translate it all again.

This new patch adds all variables with text that can be translated to hook_variable_info() .

Edit: Oops wrong issue - give me a second will come back to this one too :D

I strongly agree with @rodrigoeg that this should be solved using i18n!
From the t() API doc:

...
Translating Variables
You should never use t() to translate variables, such as calling t($text); , unless the text that the variable holds has been passed through t() elsewhere (e.g., $text is one of several translated literal strings in an array). It is especially important never to call t($user_text); , where $user_text is some text that a user entered - doing that can lead to cross-site scripting and other security problems. ...

That said I overhauled the patch to:

1. Remove calls to Drupal.t() in JS.
2. Make both "empty" messages customizable and translatable using i18n_variables
3. Straighten variable naming to "match" store locators storeLocator.Panel.NO_STORES_HTML_ / storeLocator.Panel.NO_STORES_IN_VIEW_HTML_
4. Sanitize variables with potential user input before using them.
5. Removed unused setting empty_stores_msg.

That are quite some additions but nothing to complex.

Thanks for the enhancements in the previous patch.

Some small comments I would like to add in the latest patch.

1. +++ b/google_store_locator.module
   @@ -90,11 +90,19 @@ function google_store_locator_admin_form($form, &$form_state) {
   +    '#description' => t('The message displayed if no stores are available e.h. when loading the data failed.'),
   

   What does "e.h." it mean?
   Sorry if this is a common English abbreviation, but I don't know its meaning (English is not my native language).
   Maybe it is a typo and in fact you were going to use e.g. instead.

2. +++ b/google_store_locator.module
   @@ -416,9 +425,9 @@ function theme_google_store_locator_contents($variables) {
   +    'no_results' => isset($variables['no_results']) ? $variables['no_results'] : t('There are no stores available.'),
   +    'no_results_in_view' => isset($variables['no_results_in_view']) ? $variables['no_results_in_view'] : t('There are no stores in this area. However, stores closest to you are listed below.'),
   

   Do the variables need to have default values here? I think they will always have a value at this point, because variable_get will take care of getting the default value.

Changes applied in 7.x-1.x-dev branch