HS ignores Views Settings for "Any" Label and Translations for that label

You're right, this can't be changed.

It's hardcoded in hs_taxonomy_views_hierarchical_select_root_level() in hs_taxonomy_views.module. Please roll a patch to pick up Views' setting :)

Great first attempt! :)

There are some problems though:
- The string "old-any" isn't very nice. Replace this with something cleaner, like FALSE. Also make the comparison strict (=== instead of ==), just to be safe.
- Don't do it like t('<Any>'): this forces translators to include the < and > characters in their translations. Do it like in my original line of code.
- You should assign the issue to yourself! :)

It's not my decision. It's how Drupal says it should be done. And it's true that it's impossible in Drupal to translate based on context, but that too is a design flaw of Drupal.

And

The will receive "- Tout -" in the HS form and only "Tout" in the standard exposed views form.

is not true:
- When you have '-' . t('Any') . '-' in HS and translate 'Any' to 'Tout', you get what is expected: '- Any -'.
- The above translation will *not* cause just 'Tout' to show up in the standard exposed views form, there it will stay '- Any -', since no translation for '- Any -' has been provided. You'd have to translate '- Any -' to '- Tout -' as well. Views is doing it wrong. And I see that that is where you got your idea for 'old-any'.

Ah right, it totally makes sense that it must use 'old-any'. My bad. Patch looks flawless now. Will commit tomorrow :)

Hello, I've just tested this patch, it's working fine.

One question though... views has the option of using either "" or "- Any -" and sends the strings like that to be translated, with this patch you're creating another string to be translated, witch is only "Any".
I noticed this, because I was expecting that after applying the patch, the string would show up already translated but it didn't.
I think most users will bang their heads on this for a bit... Although I think the views way of dealing with this string translation can be questioned, I believe this module should behave the same way, since that is what users are expecting.

I revised the patch to account for this.
I'm not sure if it has some code issues, because I'm not a developer, so please review it.

I just changed this:
'old_any' ? '<'. t('Any') .'>' : '- '. t('Any') .' -';
to
'old_any' ? ''. t('<Any>') .'' : ''. t('- Any -') .'';

Thank you!

Sorry, I didn't look at the v1 patch, but I've read #5 and #6.

I agree, views is doing it wrong, still, for consistency I thing this module shouldn't do it differently.

In my opinion, since views 3 is in development, we should open an issue regarding this in it's issue cue, and when HS supports views 3 change this code accordingly.


Another point for doing it the wrong (views) way is that the new drupal user will see "- Any -" in the box and that's probably what they will search for.


Just my 2 cents :P
In the end, for me, any of the options is ok...

Edit:
Ok, I went to the views issue cue, and got scared... I don't think they will change that...

We all agree views is doing it the wrong way with the "" string...
But might the "- Any -" string be in a gray area?
A new sugestion appears!

My reasoning is, if a user want's to translate the views string they have to change it to the option with the dashes, the system won't let them translate . therefor HS keeps it's code clean, and doesn't go against views using the following:

'old_any' ? '<'. t('Any') .'>' : ''. t('- Any -') .'';

Both options are translatable in HS and views is the faulty one.
What do you think?

+1

hey, so whats the status of this? which patch is kind of "supported" and what are the chances of seeing this committed soon? Thanks!

bump :) anything?

Umm, having properly read through everything, patch 2 from #7 does seem to be the more correct way for me. Tried it out on my site and works perfectly. +1 to get it committed.

Thanks!

Thanks for the reviews!

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