This is probably not the correct project to file this bug against but maybe someone in this thread knows where this should be placed.

When creating a view with a pager the next link can be translated through translate interface and has the location
views:view-name:display-name:pager:tags:next.

But in views_object::unpack_options() this becomes views:view-name:display-name:pager:next. So the tags part is lost somewhere. Anyone knows how this is possible and how to fix this?

CommentFileSizeAuthor
#3 views-2112281.patch599 bytesjax

Comments

jax’s picture

jax commented
Project: Internationalization » Views (for Drupal 7)
Version: 7.x-1.10 » 7.x-3.7
Component: Strings » Code

It seems this is a views issue:

This

      // but plugins don't because there isn't a common init() these days.
      else if (!empty($this->is_plugin)) {
        if ($this->plugin_type != 'display') {
          $localization_keys = array($this->view->current_display);
          $localization_keys[] = $this->plugin_type;
        }
      }

overwrites the correct localization_keys which were built when unpacking the options.

So when first entering unpack_options the $options are

array (size=7)
  'items_per_page' => string '2' (length=1)
  'offset' => string '0' (length=1)
  'id' => string '0' (length=1)
  'total_pages' => string '' (length=0)
  'quantity' => string '9' (length=1)
  'tags' => 
    array (size=4)
      'first' => string '« first' (length=8)
      'previous' => string '‹ previous' (length=12)
      'next' => string 'next ›' (length=8)
      'last' => string 'last »' (length=7)
  'expose' => 
    array (size=7)
      'items_per_page' => int 0
      'items_per_page_label' => string 'Items per page' (length=14)
      'items_per_page_options' => string '5, 10, 20, 40, 60' (length=17)
      'items_per_page_options_all' => int 0
      'items_per_page_options_all_label' => string '- All -' (length=7)
      'offset' => int 0
      'offset_label' => string 'Offset' (length=6)

And then at each iteration the $translation_keys are overwritten.

Shouldn't it be:

diff --git a/sites/all/modules/contrib/views/includes/base.inc b/sites/all/modules/contrib/views/includes/base.inc
index 217bbec..2d2ceb5 100644
--- a/sites/all/modules/contrib/views/includes/base.inc
+++ b/sites/all/modules/contrib/views/includes/base.inc
@@ -117,7 +117,7 @@ class views_object {
         $localization_keys = $this->localization_keys;
       }
       // but plugins don't because there isn't a common init() these days.
-      else if (!empty($this->is_plugin)) {
+      else if (!empty($this->is_plugin) && empty($localization_keys)) {
         if ($this->plugin_type != 'display') {
           $localization_keys = array($this->view->current_display);
           $localization_keys[] = $this->plugin_type;
jax’s picture

jax commented
Version: 7.x-3.7 » 7.x-3.x-dev

Still present in dev.

jax’s picture

jax commented
Status: Active » Needs review
StatusFileSize
new views-2112281.patch599 bytes

This solves my problem and doesn't seem to have other side effects.

dnlt’s picture

dnlt commented

Patch from #3 worked fine for me, too.

vegardjo’s picture

vegardjo commented
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Patch tested with success (views 3.6)

peacog’s picture

peacog commented

Patch works for me too. Thanks.

schifazl’s picture

schifazl commented

Great work, thanks! Works for me too!

dawehner’s picture

dawehner
Primary language German
commented

It would be really more soothing if this would be backed with a test.

I wonder whether the actual fix would be to set $this->localization_keys on plugins as well?

jax’s picture

jax commented

I wonder whether the actual fix would be to set $this->localization_keys on plugins as well?

I'm not sure what you mean by that. !empty($this->is_plugin) means it's a plugin...

yazzbe’s picture

yazzbe commented

#3 worked for me too. after clearing the cache. D7.26 + Views 3.7

pslcbs’s picture

pslcbs commented

#3 works fine here!!. Also Drupal 7.26 & Views 3.7

Thank you so much!!

graker’s picture

graker commented

#3 works for me as well

fernly’s picture

fernly commented

Views 7.x-3.7, #3 works fine.

dongtian’s picture

dongtian commented

Thanks a lot for patch #3, it works great for Views 7.x-3.7.

Rhodungeon’s picture

Rhodungeon commented

Patch #3 worked for me too, but I'm experiencing some problems regarding the header and footer content. Can anyone replicate this problem? You only need to edit a header and after that you should see a page with some code (ajax?).

Thanks everybody!

Rhodungeon’s picture

Rhodungeon commented

An update, it's not a problem related to the patch itself...

sinasalek’s picture

sinasalek commented

Views 7.x-3.x-dev, #3 works fine.

dawehner’s picture

dawehner
Primary language German
commented

Thank you!

  • dawehner committed fee4d81 on 7.x-3.x authored by Jax 
    Issue #2112281 by Jax: Fixed Views pager translation not working, keys...
dawehner’s picture

dawehner
Primary language German
commented
Status: Reviewed & tested by the community » Fixed

Committed and pushed to 7.x-3.x

Status: Fixed » Closed (fixed)

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