I've tried everything. even if I translate Preview in French, it still shows as Preview on the web page. Same thing with the link Thumbnail.

Where in the code is the missing t(thumbnail) and t(preview). I'm eager to fix these two.

- J

Comments

xmacinfo’s picture

Looks like the Settings/Image titles fields are lock and that these same titles are used to create the label of the image gallery links AND in the URL!

When replacing the image.module I can modify these titles. But soon after these fields are lock.

Even if I manage to rename these fields, all current picture and galleries will be mixed up.

Is there a way to only modify the link name with affecting anything else?

yched’s picture

For the record, the sizes labels were excluded from translation in this patch.

It was more of a quick fix for an embarassing problem - there should be a way to have the _displayed_ labels translated.

yched’s picture

just trying to close the bold tag in a previous post
(there's probably an underlying bug in comments management...)

yched’s picture

xmacinfo’s picture

I'm sorry for the bolding.

Indeed, there should be a new UI for the _displayed_ labels. This UI could add a new column to the size table. The new column title could be Link Label (or Label of link).

This would save a lot of user, who want to translate everything, a lot of painful headaches. I'm making a French only web site and each time an English word pops-up all are pointing fingers at me.

Cheers,

- J

xmacinfo’s picture

Component: image_gallery » image.module

The patch at http://www.drupal.org/node/43277 is for an older image.module file.

We need a new fix for the current version.

drewish’s picture

Version: 4.7.x-1.x-dev » 5.x-1.x-dev

marked these as duplicates:
http://drupal.org/node/84668
http://drupal.org/node/98865
http://drupal.org/node/159423

some other changes i've made will make it much easier for the admin to specify labels for the derivative images. once i get a few other issues taken care of i'll work on this.

vhmauery’s picture

Status: Active » Needs review
StatusFileSize
new1.41 KB

Here is a first stab. I guess it doesn't offer an interface to translate custom sizes, so it would really only work for a single-language site.

drewish’s picture

vhmauery, i'm not sure i like the approach you've taken in your patch but i'll give it a look when i've got some more time. also it has some tabs in it. spaces are the preferred way of indenting.

also, right now if you reset your image sizes to defaults you'll get the translated labels, but i was thinking it would be better to allow the admin to edit the labels for the required sizes. if you don't like preview you could change it to 'Small'...

xmacinfo’s picture

Title: Localization issue for Premiew and Thumbnail links » Reset settings default to the translated strings

Thanks for the precious information drewish,

Pressing the Reset settings in the settings/image does indeed load up the translated labels. Very old version of the image module would also translate the link, which might cause some problems if the translation used some accents.

So the effect I was looking for, display the label in its translated form, is working. This solution is fine with me because I’m doing single language sites.

On multi-languages sites, we will need a better solution. Also, the ability the change the label to something else will be a fine addition.

xmacinfo’s picture

Title: Reset settings default to the translated strings » Localization issue for Premiew and Thumbnail links

Issue title fix only.

bibo’s picture

This one has bugged me for quite a while, and I can see that I'm not alone with it. I have 2 multilangual sites under development, and this was one of the few majos annoyances that could not be "multilangualized". Drewish has done a great job with this module (fixing the 1.3 bugs and all fast) but I believe he hasn't made any multilangual sites, as this problem would be popping out a lot.

As I see it the only thing that needs to be translateable for all languages is the title of the link on the image node-page. To me is just makes sense the url query should stay the same for all languages. I also have no need to localize the variables in admin settings or the url, the only thing all users notice is really the visible/clickable part of the link (title). And it simply blows seeing small errors like that on a fully localized site.

It took me a while, but I ended up doing almost the same as vhmauery in his patch (I read his version afterwards). All credit to his patch, my version is very similar but even simpler. That is, wrapping 2 lines in t() which makes sure they can be easily localized like the rest of the page (admin-settings dont matter). This version should be fine for single and multilanguage sites, as the locale UI does all the work.

This fixes the problem for me, and I don't see it causing further problems, as image_link() (being hook_link) is only used for the links viewed on a imagenode (or am I wrong?), and changing the title through locale-module can't break anything. I may be wrong and have missed something critical about the issue, since it seems that this has been open up forever.

That was a lot of text about a patch that adds about 6 bytes to the code, but I'm just trying to make sure it's clear to everyone what the attached minimal patch does and why. The patchname also is longish to point out what exactly it does. It applies to 1.5 (and dev-since atm theyre identical).

bibo’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new32.92 KB

I know this is usually not a preferred method on issues, but I'll also upload the fully patched module (1.5) version. If you use this one, make sure to remove ".full.remove.patch" from the filename.

This is for people who want to test this on multilangual sites but don't know/can't/are too lazy to use patches. Or you could just change the 2 lines manually, in the function image_link() starting from on line 377:

function image_link($type, $node, $main = 0) {
  $links = array();

  if ($type == 'node' && $node->type == 'image' && !$main) {
    $request = ($_GET['size']) ? $_GET['size'] : IMAGE_PREVIEW;
    foreach (image_get_sizes() as $key => $size) {
      if ($size['link']) {
        // For smaller images some derivative images may not have been created.
        // The thumbnail and preview images will be equal to the original images
        // but other sizes will not be set.
        if (isset($node->images[$key]) && $node->images[$key] != $node->images[$request]) {
          if ($size['link'] == IMAGE_LINK_NEW) {
            $links['image_size_'. $key] = array(
              'title' => t($size['label']),
              'href' => "image/view/{$node->nid}/$key",
              'attributes' => array('target' => '_blank'),
            );
          }
          else {
            $links['image_size_'. $key] = array(
              'title' => t($size['label']),
              'href' => 'node/'. $node->nid,
              'query' => 'size='. urlencode($key)
            );
          }
        }
      }
    }

All there is to do is changing both occurences (on lines 390 and 397):

'title' => $size['label'],

to

'title' => t($size['label']), .

I'm also changing the status of the patch to ready, hope that's ok.

drewish’s picture

Status: Reviewed & tested by the community » Needs work

bibo, the problem with your approach is that you call t() on strings not variables. the whole .pot extraction script expects strings, not variables. doing it "right" requires calling t('Original'), t('Preview') and t('Thumbnail'). t() isn't used to translate user defined content.

bibo’s picture

Thank you for your answer Drewish!

About translating variables with t(), are you sure that is a problem? I've done a lot on my own smallish (and probably amateurish) custom modules and even themes, but I've also seen user-defined content translated in some other contributed modules.

It works fine on the site, but also creates an additional entries to the locales list (cache), if the user input changes it has to be re-translated... and I can see that leading to problems. If the source changes, there is no localization to use - until you retranslate. That won't break a site thought, unless you t()-wrap stuff that really is changing all the time.

In this case though the variable is set only in the admin settings of image-module and is very unlikely to change more than once. Even if the admin changes the settings all that needs to be done is re-translate it. Or am I wrong?

I have no doubt you have more experience and knowledge about this stuff - but this just fixed the problem fully (in my case at least) ;).

bibo’s picture

I just noticed what you ment with .pot extraction. Most modules don't even have contributed .po files. In fact I hadn't even noticed the /po/ folder of the module until now.There's even a finnish translation, surprisingly :)

I normally translate strings from contributed modules by hand, since most modules don't have pot-files. I believe most people usually do it (in http://mysite.com/admin/settings/locale/string/search). For core modules I imported the contributed translation pack tho.

The string translation page is easy to use, even if this translation was omitted from the .po files, I don't think it's a problem for any multilang-site admin to translate it on the string translation page. I don't quite see another way of easily translating all the title-names on that page, for the default derivate names + custom names for additional derivates.

Even if this doesn't make to the module, I'd just like to say that I appreciate your hard work on this module.

drewish’s picture

marked http://drupal.org/node/184074 as a duplicate

yngens’s picture

subscribe

yngens’s picture

i followed instructions in #13, unfortunately it did not make 'Original' and 'Thumbnail' strings admin/settings/image available for translation.

bibo’s picture

i followed instructions in #13, unfortunately it did not make 'Original' and 'Thumbnail' strings admin/settings/image available for translation.

Hi yngens,

It's true that the version names on the image settings page aren't translated. Afaik "Original" and "Preview" text shouldn't be changed anyway as theyre hard coded in some modules (or at least were). I don't think that's a problem though, since the version output links are what the users see, and (after applying the patch) those can be translated in "admin/settings/locale/string/search" (search for "Original" and "Preview").

The translated text is only used in the label of the links to each version, (but the filename still uses original names, like "preview"), so it shouldn't cause any problems. I guess I forgot to mention that detail. Hope this helps.

yngens’s picture

bibo, i don't mind administrators to see those strings, but the problem is that they show up in img_assist's pop-up window in english. I already translated both of the strings via Localization, but even with your suggested fix it does not change anything. and this is a serious problem for users from completely non-english countries. they often are confused and start to ask questions like 'what is thumbnail?', etc.

bibo’s picture

No wonder it dont work since img_assist is another module, altho it uses image.module. I dont use img_assist, but Ive tested it and got some old version of the module. I checked the code briefly, and seems like there is a similar solution, an one-liner too. I dont usually bother posting random stuff I havent even tested, but I'll just post what seems to work. I hope the code from this older version is the same in current img_assist.

Find this code (around line 1047 or so):

function img_assist_display(&$node, $size = NULL, $attributes = array()) {
  if (is_array($size) && ($size['label']) && ($size['width']) && ($size['height'])) { // custom size: should include values for label, width, and height
    $label = $size['label'];
  }
  elseif ($size) { // standard size
    if (is_array($size)) { // size can be an array without the width and/or height
      $size = $size['label']; // size is no longer an array
    }
    $label = $size;
  }
  else { // no size specified: assign preview size
    $label = 'thumbnail';
  }

and add after that this line (with comments if you want to):


  // Forcing each label (name of image derivate) to go through localization... I hope. It's untested!
  $label = t($label);

That should work. Or maybe not, sorry that Im not even testing it, I should be reading for my next exam which starts in 6 hours :P

yngens’s picture

Title: Localization issue for Premiew and Thumbnail links » Localization issue for Preview and Thumbnail links

Thank you for trying to help, anyway!

The code is little different now:

<?
function img_assist_display(&$node, $size = NULL, $attributes = array()) {
// Custom size should include values for label, width, and height.
if (is_array($size) && ($size['key']) && ($size['width']) && ($size['height'])) {
$label = $size['key'];
}
// Standard size.
elseif ($size) {
// Size can be an array without the width and/or height.
if (is_array($size)) {
// Size is no longer an array.
$size = $size['key'];
}
$label = $size;
}
// Assign preview size if no size specified.
else {
$label = IMAGE_THUMBNAIL;
}

?>

I tried putting suggested code

  // Forcing each label (name of image derivate) to go through localization... I hope. It's untested!
  $label = t($label);

- unfortunately it did not work.

<?
$label = t(IMAGE_THUMBNAIL);
?>

None worked

drewish’s picture

marked http://drupal.org/node/194209 as a duplicate

sun’s picture

Version: 5.x-1.x-dev » 6.x-1.0-alpha4
Priority: Critical » Normal
Status: Needs work » Needs review
StatusFileSize
new1.04 KB

Bugs get fixed in HEAD first.

Please test attached patch.

sun’s picture

Status: Needs review » Fixed

Committed.

Another fine reason to upgrade. ;)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.