Hi,

I used to retrieve data from a view using views_embed_view() and the result was correctly translated and filtered by current user's language.
I've tried to use the function views_get_view_result() instead because it is a lot simpler in my case unfortunately views does not seem to be aware of the current user's language anymore so the results are always "based on" + "translated in" the site's default language (french in my case), even on english pages.

Why ? I wish this is just an oversight and there is just a little piece of code to add to the function so that the current user's info is added to the context...

Comments

nicolas bouteille’s picture

Category: feature » bug

Switching to bug report as I think it is more appropriated.

nicolas bouteille’s picture

Nobody ? :)

dawehner’s picture

Category: bug » support
Status: Active » Fixed

Well, you have to configure the view in a way that it respects the current user language, it's not something which should/could be done automatically.

nicolas bouteille’s picture

Thank you for the reply!

Actually, I do have configured my view to 1) filter results based on the current user's language 2) translate results in the current user's language.
When I « preview » the view it works. When I create a page it works. When I use the embedding function views_embed_view() it works but I get all the wrapping html and css. Because I actually use this view to dynamically populate values of an exposed filter, I need to retrieve its values into an array. For that reason, the function views_get_view_result() fits my needs perfectly except one thing : 1) the results are not filtered based on the current language, 2) results are always displayed on the site's default language, i.e. french even on english pages.

According to me, the function views_get_view_result() should provide information to Views about the current user's language so that Views actually know which one it is. What do you think ?

nicolas bouteille’s picture

Category: support » bug
Status: Fixed » Active

I was wondering why you were not responding anymore... I had not seen that you had actually changed the status to « fixed » and the category to « support request » ... A bit quickly don't you think ?
Please can you read post #4 and provide me with your opinion on the problem ?
Thank you

Nick

merlinofchaos’s picture

Category: bug » support
Status: Active » Fixed

Ok, the problem is that views_get_view_result returns raw results.

However, with field api, the raw results aren't really even the results you're looking for. Particularly with translations.

What happens is that there is an entity that gets loaded, and run through its translation services, and things are run out of there.

One thing that might help is to NOT use views_get_view_result and instead look inside and see what that function does.

You can call $view->execute() (and possibly $view->render(), I'm not sure) and then retrieve results directly via $view->style_plugin->get_field($row_number, $field_id) where $field_id is the internal ID of the field, which is also used as an index in $view->field.

You can get the whole mess by looking at $view->style_plugin->rendered_fields.

You can check out views/plugins/views_plugin_style.inc to see how Views uses this stuff internally -- specifically check out the render_fields() method.

Also, dawehner is right; this is not a bug report, and classifying internal, raw data being different from rendered data as a bug doesn't even make sense. For one, Views doesn't even claim that raw data will look like rendered data, but two, Views isn't even responsible for how that data is dealt with. That's *data* and Views is just a layer between you and the data. This is *totally* a support request; what you're missing is understanding the relationship between the raw/rendered data, and it is understandable that the relationship is opaque to you.

nicolas bouteille’s picture

Thank you for all this precious help!
You really gave me some useful material here. Thanks!
I'll try all this and give some feedbacks later.

By the way, about the « bug report » vs « support request » thing... I know agree that it is indeed a support request! :) However... I think even though Dawehner was right in the end he was wrong to switch it to « support request » for the wrong reasons. Actually I would say the same thing about you :) (don't take it wrong, I'll explain)

Dawehner has given me the feeling that he had read my issue too fast and that he had not understood my problem. Obviously the reason why he switched it to « support request » was because he thought I just had not configured my view properly. From my point of view then, what appeared to me as being a « bug » at the time still was one.

You explained to me that I should not expect to receive translated results using the function views_get_view_result, and that actually solved my problem n°2 but not my problem 1). Indeed, I told you that I had configured a filter that was supposed to filter nodes on the current user's language (display only nodes that exist in the current user's language). Maybe I am still being confused by raw and rendered data but from what I understand any filters added to the view should be applied even on raw data no ? If I am right, that means that my filter not being applied would have been a « bug ». Still after you answered me.

Anyway, I was wrong about my « supposely bug » because the filtering actually does work well. My nodes are correctly filtered by the current user's language, I had not tested it properly and assumed it was not working, sorry about that. So it is not a bug definitely but according to me you guys couldn't have known until now ;)

Still, thank you so much for your time and your precious details !

Nick

nicolas bouteille’s picture

Title: Add current user's info to the context of views_get_view_result() » Results from views_get_view_result() are not translated
Priority: Major » Normal

So finally here is what I did to translate results of views_get_view_result :

<?php
  $term = taxonomy_term_load($viewRow->$continentTID);
  $viewRow->$continentName = i18n_taxonomy_term_name($term, 'en');
?>

The full function :

<?php
function _load_continents_a_projets(){
  
  $associativeArray = array();
  $associativeArray['All'] = t('- Any -');
  
  $viewResults = views_get_view_result('continents_a_projets', 'default');
  
  $continentTID = 'taxonomy_term_data_field_data_field_continent_tid';
  $continentName = 'taxonomy_term_data_field_data_field_continent_name';
  
  global $language;
  $language_code = $language->language;
  
  if ( $language_code == 'en' ) {
    foreach($viewResults as $viewRow) {
      $term = taxonomy_term_load($viewRow->$continentTID);
      $viewRow->$continentName = i18n_taxonomy_term_name($term, 'en');
      $associativeArray[$viewRow->$continentTID] = $viewRow->$continentName;
    }
  }
  else {
    foreach($viewResults as $viewRow) {
      $associativeArray[$viewRow->$continentTID] = $viewRow->$continentName;
    }
  }

  return $associativeArray;
}
?>
merlinofchaos’s picture

All of my assumptions are based on this:

When I « preview » the view it works. When I create a page it works. When I use the embedding function views_embed_view() it works

If it works, it's not about filtering. That led to the assumption that any discrepancies you saw were about differences between raw and rendered data.

Since all of these methods of retrieving the data will run the very same query, I discarded any notion of filtering being remotely involved and focused on the difference between what you said worked and what did not work for you. In fact, I still don't know how filtering is even relevant, based on what you said above.

Either that or you've combined several issues into one, in which case there should be no surprise that we're answering badly, because it's very difficult for us to answer multiple questions all posed as one.

nicolas bouteille’s picture

No problem, I don't want to waste your time with that kind of discussion especially knowing that the original bug wasn't even one! I really appreciated your feedback who actually led me solving my problem. I know how much you guys work for the community and I totally understand that you receive a lot of issues everyday and you are very happy when you can close them quickly.

Maybe I should spend more time next time being more clear about my problem but I still think that one was well presented. I clearly said that everything was working « perfectly except one thing : 1) the results are not filtered based on the current language, 2) results are always displayed on the site's default language »

For me there was only one bug being « the current user's language is not provided to Views by the function views_get_view_result() »
This problem was causing two drawbacks : « filtering by current user's language » + « translating »

Anyway, thank you again and congrats for Views, CTools & co, it's awesome.

merlinofchaos’s picture

At least you were able to figure out what's wrong and move forward, so that's a win all around!

nicolas bouteille’s picture

:) Yep!

Hey, I'd like to use the opportunity of having this conversation with you to talk to you about a Views add-on module I would actually like to create.
It's about :
1) populating exposed filters with dynamic values coming from another view through the UI
2) making such a dynamic exposed filter update its values on change of another exposed filter via Ajax, again through the UI

I wrote a detailled article explaining how I have managed to do all that using hooks and custom code. I know there is much chance that you won't have the time to read it, especially because it is very long, but if you ever have the time... That would really help me if you could for example :

- let me know of any improvement you would see regarding my current solution
- tell me if some of the things I say are not available with Views UI right now actually are
- tell me if you think what I want to do is realizable
- provide me with the main things I should do, tools I should use or read about before starting

All of this is very new to me and I was very happy to find a reason to finally create a module for the community, but any help would be gold to me :)

Let's not forget the link to the article ! Views AJAX Dynamic Dependent Exposed Filters

Again, I really don't expect you to read it and I will totally understand if you don't find the time to answer me further.

Have a great evening!

Status: Fixed » Closed (fixed)

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

paolomainardi’s picture

I've just stumbled upon the very same issue.

My configuration:
Views: version = "7.x-3.6"
i18nviews: version = "7.x-3.x-dev"
i18n: version = "7.x-1.8"

Terms configured as: "Localize. Terms are common for all languages, but their name and description may be localized."

Fields:
Taxonomy term: Term ID (Term ID)
Taxonomy vocabulary: Vocabulary ID (Vocabulary ID)
Taxonomy term: Name (translated) (Name (translated)) <---- This fields come from i18nviews.module (http://drupalcode.org/project/i18nviews.git/blob/refs/heads/7.x-3.x:/includes/i18nviews_handler_field_taxonomy_term_name.inc#l7)
(Parent) Taxonomy term: Name (Name)

Now, i'm using this views programmatically, language "en" (translated string in 'taxonomy_term_data_name')

 0 => 
    object(stdClass)[362]
      public 'tid' => string '11' (length=2)
      public 'taxonomy_vocabulary_vid' => string '42' (length=2)
      public 'taxonomy_term_data_name' => string 'Componenti per centrali' (length=32)</strong>
      public 'taxonomy_term_data_vid' => string '42' (length=2)
      public 'taxonomy_vocabulary_machine_name' => string 'sectionsitaly' (length=13)
      public 'taxonomy_term_data_taxonomy_term_hierarchy_name' => null
      public 'taxonomy_term_data_taxonomy_term_hierarchy_vid' => null
      public 'taxonomy_term_data_taxonomy_term_hierarchy_tid' => null
      public 'taxonomy_term_data_taxonomy_term_hierarchy__taxonomy_vocabul' => null
      public 'taxonomy_term_data_weight' => string '-1' (length=2)

As you can see "taxonomy_term_data_name" is not translated, it was supposed to be "

Now changing "views_get_view_result" function, like this:

/**
 * Get the result of a view.
 *
 * @param string $name
 *   The name of the view to retrieve the data from.
 * @param string $display_id
 *   The display id. On the edit page for the view in question, you'll find
 *   a list of displays at the left side of the control area. "Master"
 *   will be at the top of that list. Hover your cursor over the name of the
 *   display you want to use. An URL will appear in the status bar of your
 *   browser. This is usually at the bottom of the window, in the chrome.
 *   Everything after #views-tab- is the display ID, e.g. page_1.
 * @param ...
 *   Any additional parameters will be passed as arguments.
 * @return array
 *   An array containing an object for each view item.
 */
function views_get_view_result($name, $display_id = NULL) {
  $args = func_get_args();
  array_shift($args); // remove $name
  if (count($args)) {
    array_shift($args); // remove $display_id
  }

  $view = views_get_view($name);
  if (is_object($view)) {
    if (is_array($args)) {
      $view->set_arguments($args);
    }
    if (is_string($display_id)) {
      $view->set_display($display_id);
    }
    else {
      $view->init_display();
    }
    //$view->pre_execute();
    //$view->execute();
    $view->preview(); 
    return $view->result;
  }
  else {
    return array();
  }
}

I have the right results:


array (size=22)
  0 => 
    object(stdClass)[362]
      public 'tid' => string '11' (length=2)
      public 'taxonomy_vocabulary_vid' => string '42' (length=2)
      public 'taxonomy_term_data_name' => string 'Componenti per centrali termiche' (length=32)
      public 'taxonomy_term_data_vid' => string '42' (length=2)
      public 'taxonomy_vocabulary_machine_name' => string 'sectionsitaly' (length=13)
      public 'taxonomy_term_data_taxonomy_term_hierarchy_name' => null
      public 'taxonomy_term_data_taxonomy_term_hierarchy_vid' => null
      public 'taxonomy_term_data_taxonomy_term_hierarchy_tid' => null
      public 'taxonomy_term_data_taxonomy_term_hierarchy__taxonomy_vocabul' => null
      public 'taxonomy_term_data_weight' => string '-1' (length=2)
      public 'taxonomy_term_data_name_i18n' => string 'FRANCESE Componenti per centrali termiche' (length=41) // translated fields

If you need more details, please let me know.

paolomainardi’s picture

Issue summary: View changes

replacing language by info to make it more general