Originally described my problem in http://drupal.org/node/341993#comment-2389072 but since a patch was already committed on that issue I guess this problem needs a new issue.

If you have:
1. a multilingual site, I18n installed and language negotiation set to "Path prefix with language fallback"
2. a taxonomy vocab set to "Localize terms. Terms are common for all languages, but their name and description may be localized."
3. HS enabled for that vocabulary: "Use the Hierarchical Select form element for this vocabulary"
4. Use a language other than the default to create content, or administer the vocabulary

HS fails to retrieve terms correctly.

Currently my default language is english (no path prefix), if I switch to french to administer the vocabulary the terms do appear in the HS widget preview, until it is clicked on - they then disappear and the selection list is empty.

When creating a new node in english HS works perfectly for the configured vocabulary. If I switch to french the selection list is empty (the terms *do* have translations available).

There are no errors thrown either in drupal or firebug, so it's hard to tell where this problem starts, but I'm guessing it's the client side js since the terms do appear in the widget preview on the vocab admin page.

Files: 
CommentFileSizeAuthor
#11 683574-11.patch826 bytesroderik
#8 hierarchical_select-683574.patch807 bytesmiruoss

Comments

Status:Active» Postponed (maintainer needs more info)

There are no errors thrown either in drupal or firebug, so it's hard to tell where this problem starts, but I'm guessing it's the client side js since the terms do appear in the widget preview on the vocab admin page.

HS uses the exact same logic when JS is disabled and when JS is enabled. In the latter case AHAH updates are used.

So there's any easy way to find out if the JS is to blame: disable JS in your browser for a minute. If that fixes the problem, then it's HS' JS that is to blame. :)

Ah, cheers!

It's still broken with js disabled :/
At least that narrows things down a little. Config, php code or module clashes...

I bet it's either of these settings:

1. a multilingual site, I18n installed and language negotiation set to "Path prefix with language fallback"
2. a taxonomy vocab set to "Localize terms. Terms are common for all languages, but their name and description may be localized."

For:
1. Well, that's rather the point, it's a bug. The question is why?
2. I can set the translation mode for the vocabulary to any of the 4 options and HS always fails for french, works for english (default).

Some more progress in outlining the issue:

I've played with settings on the multilingual tab for language admin ( at admin/settings/language/i18n ).

If I change 'Content selection mode' and visit the node/add form in french, each options gives:

* 'Current language and language neutral' –> empty hs widget, no terms retrieved.
* 'Mixed current language (if available) or default language (if not) and language neutral.' –> retrieves the french terms! Yay!
* 'Only default language and language neutral' –> retrieves the french terms.
* 'Only current language' –> empty hs widget, no terms retrieved.
* 'All content. No language conditions apply.' –> retrieves the french terms.

So it seems there is only an issue with HS when 'current language' is specified for this setting.

I'm about to test how a standard taxonomy selection form behaves under these conditions for comparison.

Status:Postponed (maintainer needs more info)» Closed (works as designed)

It seems the standard taxonomy selection widget also returns empty under these conditions - I suspect this is because a few of the vocabularies terms have not yet been localized, so the whole vocab can only be displayed if a 'mixed' language selection is used.

So nothing to do with HS at all. And the fix was to set 'Content selection mode' to 'Mixed current language (if available) or default language (if not) and language neutral.'

Marking this as 'by design'.

Apologies for wasting your time.

I have exactly the same problem, but unfortunately I could not solve it with the suggested solution in #6.

My site has three languages and much of the information is organized by geographical location. So I did a Vocabulary in Taxonomy with the structure "Country / Region / City." I have English as default language. I translated the Vocabulary Terms with the help of the module translation_table ton the other two languages. I made a field for the location with CCK in a content type using a Hierachical Select widget that gives me a drop down menu with the countries, when I choose a country the regions in that country appears, and when choosing a region the cities in that region appears.
I create new content first in English, so far so good, but when I try to translate this page to another language there is no information in the drop down - nothing...
I am a Drupal newbie, and would be extremely happy if anyone could point me in the right direction so I can solve this problem?

Status:Closed (works as designed)» Needs review
StatusFileSize
new807 bytes

I had the very same problem. I browse my page in a certain language (let's say English) and create edit a node of a different language (German). At first the drop down shows the correct (German) terms. However, when I change the selection, the ajax call to retrieve the children returns a new dropdown with English terms.

So I tried to found a solution. I think the problem is that in the context of the method hierarchical_select_json() we should change the language selection mode to "node" with the submitted language as argument. Changing the selection mode to "node" is exactly what Drupal does when a node is created/edited in a particular language.

I added the following code to hierarchical_select_json() (at the top of the method somewhere). Now my drop down works as I expect it:

<?php
 
// in this context, we're in a node selection mode
 
if (module_exists('i18n') && isset($_POST['language'])) {
   
i18n_selection_mode('node', $_POST['language']);
  }
?>

I also attached a patch that can be applied against 6.x-3.x-dev.

Status:Needs review» Fixed

Thanks miruoss. Committed!

http://drupal.org/cvs?commit=389230

Status:Fixed» Closed (fixed)

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

Version:6.x-3.0» 6.x-3.7
Status:Closed (fixed)» Needs review
StatusFileSize
new826 bytes

Unfortunately, the core translation.module sometimes disables the 'language' form element.

So the attached patch is necessary to ensure we $_POST['language'] is filled.