Marker titles are not translated

And that issue is not likely to be fixed.

So the only practical method looks to be the approach Gábor suggested in that issue:

having a function you never call with t() calls in them was one workaround people used so far to get static strings into the generated templates. And you can of course add that to a never included .inc file, potx does not see whether you include it or not.

Specifically, this would be:

1. Create a file, e.g., gmap.strings.inc. Put a function in it, e.g.,

function gmap_markers_labels_potx() {
  $marker_labels = array();
  ...
  return $marker_labels;
}

2. Look though the .ini files in /markers. For each of the labels, e.g.

[defaults]

write a line in the function to declare that string:

$marker_labels[] = t('defaults');

Or else here's a script that will write at least something like what's needed:

$markerdir = variable_get('gmap_markerfiles', drupal_get_path('module', 'gmap') .'/markers');

// The following routines are designed to be easy to comprehend, not fast.
// This whole process gets cached.

// Get the ini files.
$inifiles = file_scan_directory($markerdir, '.*\.ini$');

$labels = array();
foreach ($inifiles as $file) {
  $icon_data = parse_ini_file($file->filename, TRUE);
  foreach ($icon_data as $icon_set) {
    if (isset($icon_set['name'])) {
      $labels[] = "t('" . $icon_set['name'] . "'),";
    }
  }
}

print "<?php\n\nfunction gmap_marker_labels() {\n";
print "return ";
print_r(array_unique($labels));
print ";\n";
print '}';

Here's a patch with a version of Nedjo's script modified to write the file to the dir, and more importantly, some explanatory commenting. This patch also adds the actual .inc file.

I've reviewed the patch and it partially works. The patch provides a gmap.strings.inc file containing all of the marker labels wrapped in t() calls. Also, using the newly created gmap.strings.php script, I was able to create an updated version of this file. Once the gmap.strings.inc file was present in the gmap directory, I was able to extract these strings for translation using the POTX module.

The only thing I haven't been able to do is to go to admin/build/translate/search and search for a marker label and translate it. I've tried clearing the cache, ensuring I used the correct case, etc, to no avail.

I also tried extracting the strings, translating them and then importing the translated versions back into Drupal. Even when I do this the strings do not appear translated in the form.

Cheers,
Stella

I've changed the name of the function in the created gmap.strings.inc to be gmap_marker_labels_potx(), as opposed to gmap_marker_labels(), made a slight adjustment to the way the $marker_labels array is constructed, and regenerated the gmap.strings.inc file to be included in this patch with the amended gmap.strings.php script which creates the include.

I've tested an extract of the gmap module using potx, and all strings in the generated include file are present as translatable in the resulting .pot, an example of i will attach here.

This patch doesn't address any of the issues I highlighted.

Here's the outstanding issues:

• The marker strings can not be found via the search tool at admin/build/translate/search
• Even when you do extract the strings using potx module, translate them into French or another language and then import the translated strings, the marker strings still appear in English on admin/settings/gmap
• gmap.pot should actually be called gmap-module.pot

Cheers,
Stella

Hailu, thanks for continuing to work on this, it's coming along well.

To complete the patch, we need to identify all places where the marker titles are output and ensure they're passed through t().

See e.g. the function gmap_get_marker_titles(). This is one of the places.

We'll be passing a variable through t(), which is usually not the right approach, but here it is right, since we've ensured that the strings are properly processed elsewhere.

I've concatenated the marker names within a t() call within the initial array taken from _gmap_get_marker_titles() which seems to be where all titles originate from, so this should fix the main issue Stella reported. Can't get the potx extractor to work on my install at the moment, so this is untested other than examining the arrays to ensure it's outputting array('name' => t('Name'));

I have concerns about the general approach - since the marker names generally have a 1-1 mapping with file names (i.e. "White" and "white.png") - and since these are only translated in the admin area, seems almost better to leave them untranslated. But that doesn't prevent getting the patch working so I'll mark back to needs review. Another option would be (Vert) Green (suggested by Nedjo), but without a module_exists() check for locale and current language, we'd be doing (Green) Green if viewing in English.

I tested availability of strings to potx module locally, and resulted in the attached .pot where strings are accessible, so this functionality seems intact. I'm not sure about the additional check for module_exists().

Re-roll of patch. The patch in comment #9 introduced a bug where the t() function was treated as a string and was visible in the markers drop down lists. I've changed this to not be a string, but this means t() is being called on $variables. Perhaps we should change this to use i18n's tt() if available? However, these strings should never change really - they're read in from an ini file.

With this version of the patch, it's possible to search for the marker titles at admin/build/translate/search and translate them. The strings are only available for translation once you view the settings page (where they're loaded) in a non-English language.

Cheers,
Stella

Thanks stella, this is good to go then.

Calling t($variable) is okay provided the value is elsewhere passed through t() (or otherwise extracted by potx) correctly.

The value is passed through t() elsewhere - in gmap.strings.inc

Thanks to all for the patch.

Committed to 5, 6 & 7.

http://drupal.org/cvs?commit=379178
http://drupal.org/cvs?commit=379176
http://drupal.org/cvs?commit=379180

I can't get my translations done for this module.

For instance: I'm using this in my settings.php:

$conf['i18n_variables'] = array(
  'gmap_node_map[header]',
  'gmap_node_map[footer]',
);

But doesn't seem to respond.

Is this module still maintained?

I've got another problem: when two menu items (each from a different language) point to "map/nodes" the submenu just disappears...

You realise you only waited for a reply for 2 minutes after posting to ask if the module was being maintained?

It is maintained as much as possible given the current maintainers spare time (which is currently minimal).

I'm sure if someone wanted to put their hand up to be a maintainer, who had a lot of time to put into it bdragon would make them a maintainer.

Multilingual is not really one of my areas of expertise, so off the top of my head I can't help you and I haven't the time to investigate it.

Someone else may know though.

#16 was actually posted months ago, but was edited (removed a link that wasn't that mentionable), hence it looked like it was just 2 minutes ago - as the orignal date of posting isn't displayed anymore. Needless to say I realise that (it took about two minutes to write the post following it) - which made it a quite funny remark :)

After posting the previous remark it occured to me that this is a legacy module. I'll look for one the alternatives that are mentionned on the project page (e.g. Get Locations).