Hierarchical Select: use the special translation function provided by the i18n module

zmove - December 3, 2008 - 07:59

Project:	Hierarchical Select
Version:	6.x-3.x-dev
Component:	Code
Category:	task
Priority:	normal
Assigned:	Unassigned
Status:	needs work

#1

zmove - December 3, 2008 - 08:39

I think I found the problem, Hierarchical select taxonomy is not compatible with i18n.

My taxonomy have the option "localized term" to be able to translate them via the local system. This is a i18n taxonomy option.

When I disable this option, my hierarchical select work, so I tried to identify what could be the cause of that problem.

I noticed that i18n_taxonomy have a "10" weight in the system table, whereas hs_taxonomy have a weight of 0.

Putting a higher weight to hs_taxonomy make my hierarchical select for taxonomy appear. So, I think this is a first step.

However, the ajax term selection don't work, when I select a first term, the children selection never appear and javascript crash. If I refresh the page, I get an error :

<?php
    * warning: Missing argument 2 for drupal_retrieve_form() indrupal6includesform.inc on line 320.
    * warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '' was given in drupal6includesform.inc on line 366.
    * warning: uasort() [function.uasort]: The argument should be an array in drupal6includescommon.inc on line 2731.
?>

Is there a chance to see hs compatible with i18n ? I could point the problem, but I think I'm unable to fix it.

#2

zmove - December 3, 2008 - 08:40

Title:

Hierarchican select taxonomy don't appear on the node creation page

» HS taxonomy incompatible with i18n. The result is that HS taxonomy form don't appear.

Better title

#3

zmove - December 3, 2008 - 09:25

Title:

HS taxonomy incompatible with i18n. The result is that HS taxonomy form don't appear.

» Taxonomy selection crash when selecting parent term + PHP error

Hi again,

In fact I'm not sure its related to i18n. I tested to disable i18n taxonomy again, and the HS taxonomy sselection still crash.

The issue related to the module weight is still avaiable, hs_taxonomy need a +20 weight to appear when i18n taxonomy is enabled.

I will continue a little my investigation about children selection crashing.

#4

zmove - December 3, 2008 - 09:46

Title:

Taxonomy selection crash when selecting parent term + PHP error

» Hierarchical select Taxonomy and i18n Taxonomy conflict

Hi,

I finally found the problem, and I have a solution.

So, to start from the begining :

i18n taxonomy have a weight of 10 in the system table and hs_taxonomy have a weight of 0. This result than the hs_taxonomy taxonomy form was replaced by i18n taxonomy form cause i18n taxonomy hook_form_alter() was called after hs_taxonomy.

So, I firstly put a weight of 20 to hs_taxonomy to override the i18n taxonomy form. It worked, but hs_taxonomy had a better weight han hierarchical_select.module (which have a weight of 11), that was the cause of the PHP error problem above...

I tried to put the same weight to hs_taxonomy than hierarchical_select (so, 11) but it don't work. hierarchical_select need a greater weight than hs_taxonomy.

So, the solution

Very simple, the solution is to put a weight of 12 to hierarchical_select and a weight of 11 to hs_taxonomy. Like that, the hs_taxonomy weight is greater than i18n taxonomy but not in conflict with hierarchical select.

I don't think changing weight will impact on others functionnalities, so I think it can be ported.

I don't know if the hs_taxonomy terms take care of i18n taxonomy translation cause I only have terms in english ATM, so, maybe it not resolve multilanguage taxonomy, but I think it's another issue, and it's a feature request, not a bug report.

#5

Wim Leers - December 3, 2008 - 10:13

Component:	Code	» Code - Taxonomy
Assigned to:	Anonymous	» Wim Leers

hs_taxonomy takes care of translated terms, so yes, in that sense it's compatible with i18n Taxonomy.

I hadn't checked the module weights yet on Drupal 6, but a similar thing had to be done on Drupal 5. Only i18n Taxonomy's weight has changed in D6, causing you these problems.

Thanks for figuring out the details for me! :)

#6

sdecabooter - December 18, 2008 - 09:52

I confirm that the solution suggested by zmove seems to fix the problem.
I also did some basic tests translating the terms, which did not seem to break anything.

#7

chaloalvarezj - February 13, 2009 - 05:52

Changing the weights as stated by zmove in #4 solved the problem of not having the hierarchical select working when i18n was installed... However, my translatable terms are not displaying the translated terms as they should... Should I open a new issue? DOes anybody else have this problem?

#8

chaloalvarezj - March 10, 2009 - 07:07

Bump... Anyone else experiencing this problem?
I have changed the weights to 12 for hierarchical_select and to 11 for hs_taxonomy. This made the hierarchical select to show correctly on the node types where it is used. However, translation for the translation mode: Localize terms, are not translated.

- Localize terms. Terms are common for all languages, but their name and description may be localized.

I even changed to none first, saved, and changed to localize terms again...

sdecabooter: are you using the "Localize terms" option? <- just knowing this will help me when looking for something else

UPDATE: I noticed that this module is using the t() function to translate taxonomies, when it is recommended to use the tt() function provided by i18n for user generated translations.
around line 395 of hs_taxonomy.module there is the following code:
// Use the translated term when available!
$labels[$item] = t($term->name);
And on line 745:
// Use the translated term when available!
$options[$term->tid] = t($term->name);
This code isn't working either.. just after selecting a "translated" term... they all get reloaded in English again (loosing the translation).

#9

Wim Leers - March 20, 2009 - 18:13

Assigned to:	Wim Leers	» Anonymous
Status:	active	» postponed (maintainer needs more info)

Could you please post a patch? Right now it's just a mix of various conclusions that don't go together well. Thanks.

#10

chaloalvarezj - March 23, 2009 - 08:24

I would like to give it a shot, but unfortunately, I don't have a development environment... and I don't understand where and how the selection list gets reloaded... Is it cached when the page loads? Is it loaded using javascript? As I said before, I get to show the first selection box translated (using tt() from i18n).. but it is all lost after selecting (clicking) a term.

#11

Wim Leers - March 23, 2009 - 09:40

Disable JavaScript and it'll still work. You can then apply your changes while ignoring any "special JS stuff".

#12

chaloalvarezj - March 24, 2009 - 00:34

Hi again,
I have tried disabling JavaScript on my browser, and it seems to be working... so for the time being, how do I disable the JavaScript part of the module? (at least the automatic reload).

From this test, we know that:
1) the t() function works with JavaScript disabled;
2) the t() should be replaced by tt();
3) there is a problem somewhere in the JavaScript that load the terms without translating.

#13

Wim Leers - March 24, 2009 - 10:25

1) obviously. Also when JS is enabled. The code path used is exactly the same, so it must be something special you're using that causing the odd behavior.
2) No. tt() isn't part of core and therefor I won't use it. If this is wrong according to you, then please link me to the piece of documentation that states his.
3) No, see 1.

To disable the JS part, set Drupal.settings.HierarchicalSelect.pretendNoJS = true;.

#14

chaloalvarezj - March 24, 2009 - 14:27

Thank you for your reply,
I have set Drupal.settings.HierarchicalSelect.pretendNoJS = true;
And the translation now works...
1) with JS enabled, the translation did not work even when using the module as is, i.e, using t() translation. As I said before, the translation load correctly, but changes to the untranslated term when an item is selected.
2) about tt(), there is nothing that says it should be used; on the other hand, there are some discussions about the misuse of t() and the documentation (see t() usage documentation inside common.inc) clearly states that some helper module should be used to translate user generated strings (i.e., vocabularies, terms, menus, etc.)
References:
http://groups.drupal.org/node/15177
http://drupal.org/book/export/html/322729
http://drupal.org/node/336115
http://drupal.org/files/issues/t-docs_0.patch
3) Will try to create a sample to reproduce the behavior explained in 1. Will help if someone else could also report on this.

Would like to be more helpful, but I am just starting to deep into drupal.

Cheers

#15

Wim Leers - March 24, 2009 - 17:03

Title:	Hierarchical select Taxonomy and i18n Taxonomy conflict	» Hierarchical Select: use the special translation function provided by the i18n module
Component:	Code - Taxonomy	» Code
Category:	bug report	» task
Assigned to:	Anonymous	» Wim Leers
Status:	postponed (maintainer needs more info)	» active

The only usable piece of documentation seems to be http://drupal.org/book/export/html/322729. I'll look into that when I have the time.

#16

Tim Chan - June 19, 2009 - 03:23

Regarding chaloalvarezj's problem (post #10), the cause is that HS wrongly changes the current language to the default language (English) on JSON callbacks. Here is a quick and dirty solution:

1)
On site database system table, change the weights of hierarchical_select and hs_taxonomy to 12 and 11 respectively. This makes the HS display.

2)
Edit hierarchical_select.module like this:

// BEFORE EDIT
...
function _hierarchical_select_setup_js() {
  ....
  $url .= 'hierarchical_select_json';
  ....
}
...

// AFTER EDIT
...
function _hierarchical_select_setup_js() {
  ....
  $url .= 'hierarchical_select_json';
  if (module_exists('i18n')) {
    $url .= '/';
    $url .= i18n_get_lang();
  }
  ....
}
...

3)
Edit hs_taxonomy.module like this:

First, add the below function somewhere.

/**
 * Localize a term by replacing its name attribute with its localized version
 * for the current language.
 *
 * @param $term
 *   The term to localize, with at least tid, vid, and name data members.
 *
 * This is based on i18ntaxonomy_localize_terms(), but with less overhead.
 */
function _hs_taxonomy_localize_term(&$term) {
  // If this term's vocabulary supports localization.
  if (module_exists('i18ntaxonomy') && i18ntaxonomy_vocabulary($term->vid) == I18N_TAXONOMY_LOCALIZE) {
    if (array_key_exists( arg(1), i18n_language_list() )) {
      $term->name = tt("taxonomy:term:$term->tid:name", $term->name, arg(1));
	} else {
	  $term->name = tt("taxonomy:term:$term->tid:name", $term->name);
	}
  }
}

Then make the below changes:

// BEFORE EDIT
...
function hs_taxonomy_hierarchical_select_item_get_label($item, $params) {
  ...
  $labels[$item] = t($term->name);
  ...
}
...
function _hs_taxonomy_hierarchical_select_terms_to_options($terms) {
  ...
  $options[$term->tid] = t($term->name);
  ...
}
...

// AFTER EDIT
...
function hs_taxonomy_hierarchical_select_item_get_label($item, $params) {
  ...
  _hs_taxonomy_localize_term($term);
  $labels[$item] = $term->name;
  ...
}
...
function _hs_taxonomy_hierarchical_select_terms_to_options($terms) {
  ...
  _hs_taxonomy_localize_term($term);
  $options[$term->tid] = $term->name;
  ...
}
...

4)
Hopefully you will get HS perfectly translated.

#17

rapsli - June 29, 2009 - 07:01

#16 this fix works only partially. If the dropbox is enabled and you add multiple terms, then the 2nd try doesn't contain translated terms anymore.

#18

Wim Leers - July 19, 2009 - 22:44

This has been fixed for D5 yesterday: http://drupal.org/node/487048#comment-1825714. Maybe the same code can be applied to D6? This should at least help this issue somewhat forward.

#19

makara - July 21, 2009 - 10:48

Status:

active

» needs work

Hi,

This is the patch works for me. It's a little different with #16.

Please review. Cheers!

EDIT: This patch was developed for a project led by Wiredcraft.

Attachment	Size
hierarchical_select_i18n.patch	2.8 KB

#20

Wim Leers - July 21, 2009 - 10:26

Status:

needs work

» needs review

Excellent, makara. Thanks :)

Can others please review this?

#21

Wim Leers - July 21, 2009 - 10:26

Assigned to:

Wim Leers

» Anonymous

#22

Wim Leers - July 29, 2009 - 20:07

Nobody who can/wants to review this?

I'll then just commit it if you can confirm this is being used in production, makara :)

#23

makara - August 5, 2009 - 08:34

Yes, we are using it in production.

#24

Shawn_S - August 5, 2009 - 08:54

I have an issue in which some parts of this module won't run on my version (6.13) of Drupal. That is another problem but lead me to a part of this patch that I had to modify to get it to run.

In the file hierarchical_select.module::function _hierarchical_select_setup_js() there is test to see if i18n is installed before trying to get the language specific url. In the patch this test uses:

<?php
if (module_exists('i18ntaxonomy'))
?>

I had to change mine to test for:

<?php
if (module_exists('i18n'))
?>

I am not using taxonomy at all and simply wanted the menu selection to make it easier for content editors. This seems to work. Wouldn't it perhaps be better just to test for the simplest module that would allow you to use i18n_get_lang() ?

BTW: Thanks makara for the patch, it has been a great help!

#25

Shawn_S - August 5, 2009 - 08:59

Oh heck, Tim Chan refers to this in #16 already - Step 2

#26

Wim Leers - August 5, 2009 - 13:07

@makara: if Shawn_S hadn't posted his comments, I'd have committed your patch. However, it seems your patch doesn't cover all cases, because of Shawn_S' comments. Could you please investigate this closer? Maybe collaborate?

#27

Wim Leers - August 11, 2009 - 09:24

Status:

needs review

» needs work

#28

makara - August 14, 2009 - 17:53

Status:

needs work

» needs review

Thanks Shawn_S.

I changed that.

Attachment	Size
hierarchical_select_i18n_1.patch.txt	2.79 KB

#29

Annalog - August 18, 2009 - 06:12

Category:

task

» support request

I use the latest i18ntaxonomy commit http://drupal.org/node/531710, which works fine when hs_taxonomy is not enabled. But I need hs_taxonomy for some large vocab.

My problem is the forum.

I don't need hs_taxonomy for the forum vocab, but hs_taxonomy_form_alter takes over anyway. Makara's patch shows the localized terms (thanks, makara!), but the form item isn't set to required.

Can I deactivate the override for certain vocabularies?
Or how do I let the forum vocabulary form be required also in the hs_taxonomy?

If that should be a stupid question: I'm just starting to get deeper into drupal, sorry.

#30

Wim Leers - August 18, 2009 - 07:03

Category:

support request

» task

Annalog: this is a very inappropriate hijack of this issue. *Don't* do that again in the future. To answer your question: go to Admin > Content > Taxonomy. Click on the "Forum" vocabulary and set it to required. It's that simple.

#31

Annalog - August 18, 2009 - 15:25

That's what I did. But the hs_taxonomy_form_alter was executed anyway (at least devel said that). My error was in the weights, that I had changed regarding the first post here. Sorry also for double-posting without noticing it.

At least I can maybe review a bit: the last patch doesn't work for me in other than source language, for no vocabulary now (Received an invalid response from the server.)

#32

Wim Leers - August 18, 2009 - 15:57

I won't answer your question here. Please *do* open a new issue.

#33

edster. - August 19, 2009 - 14:33

Hi, I have been testing the patch attached to #28 on two seperate sites with different language negotiation settings:

1) Language negotiation set to: Path prefix only.
2) Language negotiation set to: Domain name only.

On site 1 I received an "invalid response from the server" while in the sites default language, it worked fine for other languages, after looking into it I found that I had not set a path prefix for the default language, so when I applied this patch it was adding the language prefix on the JSON callback and as a result gave an error, I then added a path prefix to the default language and it worked.

On site 2 I also received an "invalid response from the server" for both languages that were enabled on the site, again because neither language used a path prefix since two seperate domain names determine the language.

As a solution I added two extra conditions to the if statement to cover the differnet language negotiation options given by the locale module. The first condition checks if the current language is not the default since, as far as I know, by default drupal does not use/need a path prefix for the default language. The second condition checks if the language negotiation is not set to Domain name only. This makes sure that the prefix is only added when its required.

I have added the code below that I used in hierarchical_select.module

// BEFORE
...
  $url = base_path();
  $url .= variable_get('clean_url', 0) ? '' : 'index.php?q=';
   if (module_exists('i18n')) {
      $url .= i18n_get_lang() .'/';
   }
  $url .= 'hierarchical_select_json';
...

//AFTER
...
  $url = base_path();
  $url .= variable_get('clean_url', 0) ? '' : 'index.php?q=';
   if (module_exists('i18n') && i18n_get_lang() != i18n_default_language() && variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE) != "3") {
      $url .= i18n_get_lang() .'/';
   }
  $url .= 'hierarchical_select_json';
...

I have tested this on both sites and it is working fine, hope this helps!

PS:Thanks to makara for the patch, its been a life saver!

#34

Wim Leers - August 19, 2009 - 20:20

edster.: could you please update the patch itself and then post it here? Thanks!

#35

edster. - August 20, 2009 - 10:55

here is the updated patch

Please review, thanks!

Attachment	Size
hierarchical_select_i18n_2.patch	2.9 KB

#36

Wim Leers - September 21, 2009 - 12:56

Can somebody else test this please? Thanks!

#37

chaloalvarezj - September 29, 2009 - 07:57

Hi there,
I have manually applied the patch in #35 to the dev version of September 24th... and so far seems to be working perfectly with translatable terms and language prefix after base domain. Thank you @makara and @edster... and of course thanks to @Wim Leers for this module.
Cheers

#38

Wim Leers - September 29, 2009 - 14:15

Status:

needs review

» fixed

Excellent! Thanks for your feedback chaloalvarezj! :)

Committed: http://drupal.org/cvs?commit=269014.

@makara and edster.: I'm so sorry! I'm massively-multi-tasking (20+ things) and in the process forgot to credit you guys … :(

#39

System Message - October 13, 2009 - 14:20

Status:

fixed

» closed

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

#40

barnstormer - November 9, 2009 - 00:33

Status:

closed

» needs work

I'm on Drupal 6.14 with the 3.x dev 2009-Nov-01 version of the module which I downloaded last night. I'm still seeing this issue as originally reported.

With the localization modules on, and the Translation mode set to "Localize terms. Terms are common for all languages, but their name and description may be localized." HS does not appear on node add/edit. With the Translation mode set to "None" it works fine.

I haven't tried tinkering with module weight settings, but it sounded like this patch should resolve the issue without having to do any of that.

I shouldn't have to do anything extra, right? Should just work out of the box w/ the latest dev release?

Anyone else still seeing this?

Hierarchical Select: use the special translation function provided by the i18n module

Jump to:

User login

Contributor links