Better i18n support [#314777]

This patch sets the correct language of the UI elements provided by GMap2 API and allows marker names to be translated.

The latter can probably be backported to d5 directly.
I believe that the former will require usage of the global variable $locale.

Comment	File	Size	Author
	gmap_i18n.patch	1.51 KB	Bevan

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

nedjo

he/him/his

English

CreditAttribution: nedjo commented 29 September 2008 at 20:08

Status:

Active

» Needs work

The fix to pass the language looks great.

For localization of strings, in general there's an attempt to move away from passing variables through t(); see

Instead we could rely on the i18nstrings module, if present. Here's a draft:


$title = $inis[$ini][$k]['name'];
if ($module_exists('i18nstrings')) {
  $title = tt("gmap_marker:$ini:$k", $title);
}
$titles[$k] = $title;

Comment #2

Bevan CreditAttribution: Bevan commented 30 September 2008 at 01:51

Status:

Needs work

» Postponed (maintainer needs more info)

What is wrong with passing the variable through t()? The value of the variable is a hard coded string in .ini text files, where t() is unavailable. Also the resulting list of translated titles is cached and only expires when the cache is cleared manually (I believe).

I trust there is a good reason, but I don't understand what it is! :) Thanks

Comment #3

nedjo

he/him/his

English

CreditAttribution: nedjo commented 1 October 2008 at 15:12

My current understanding is:

Potx module and the equivalent script can't extract strings to be translated when they are variables.

Modules that pass variables through t() make it possible for users to localize strings through the Drupal UI, but these strings are all jumbled together. It's not feasible then to produce .po files for them, because they have no context (there's no indication of what kind of strings they are).

The i18nstrings module addresses this issue by using the D6 locale system the way it's supposed to be used--creating a separate 'group' for each type of string.

As you point out, in this case the strings in question at least aren't admin-entered and so can't be changed, so we don't have to worry about one of the main issues--updates.

The other way this could be addressed might be to pull the configuration out of .info files and into a PHP file where strings can be passed through t().

Comment #4

Bevan CreditAttribution: Bevan commented 1 October 2008 at 21:40

> The other way this could be addressed might be to pull the configuration out of .info files and into a PHP file where strings can be passed through t().

I assume you mean .ini files, not .info files. Having the Marker Titles in .ini files is somewhat convenient because the data is in a simple, easy to edit format that non-php programmers can edit more easily (designers are likely to want to add marker icons here), and is next to the markers. Refactoring the marker code would also result in quite a lot of changes with very little enhancement.

So I guess the question is, is that effort worthwhile?

Can we not pass the variables through t() at all? What about something like

 if (module_exists('i18nstrings')) {
  $titles[$k] = tt("gmap_marker:$ini:$k", $inis[$ini][$k]['name']);
}
else {
  $titles[$k] = t($inis[$ini][$k]['name'])
}

as a compromise, which allows the markers to be translated if i18nstrings module isn't available? Or does this still not solve the problem with potx.module?

Comment #5

nedjo

he/him/his

English

CreditAttribution: nedjo commented 2 October 2008 at 15:58

Bevan, I suggest you move the GMap 2 API portion of this patch to a separate issue, as that looks ready to go. Then we can continue to work out the best approach to localizing the strings.

Thinking about this some more, I'm concluding i18nstrings is not the right answer, because these are not user-entered strings. What we want is a way to get these strings where they belong, in .pot files.

The potx module, http://drupal.org/project/potx, has relevant functionality. As part of its string extraction, It parses .info files and reads in relevant strings. So the right solution, it looks like, would build on potx and enable potx correctly to extract these strings.

So probably this depends on issue #303865: Add a hook_localize() on potx module. I've just commented there.