Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Under Site Building > Views > Tools it is possible to select the display type of the "Any"-Label:
< Any > (there should be no spaces between brackets and text, but the text editor would remove the whole string)
or
- Any -
HS ignores the setting of this selection and displays always < Any >.
Furthermore I think that translations (via Site Building > Translate interface > Search, search and translate < Any > string) are ignored. In every language HS displays < Any >.
How can that be fixed? thanks for any help
Comment | File | Size | Author |
---|---|---|---|
#9 | hs_taxonomy_views_module_ANY-v3.patch | 771 bytes | Jolidog |
#7 | hs_taxonomy_views_module_ANY-v2.patch | 771 bytes | no2x |
#3 | hs_taxonomy_views_module_ANY.patch | 754 bytes | no2x |
Comments
Comment #1
no2x CreditAttribution: no2x commentedHas anyone else the same problem?
Comment #2
Wim LeersYou'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 :)
Comment #3
no2x CreditAttribution: no2x commentedOk so here's a patch. I took the code from views/handlers/views_handler_filter.inc line 465 (function exposed_translate).
For me it works now.
Comment #4
Wim LeersGreat 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! :)
Comment #5
no2x CreditAttribution: no2x commentedok i will update that.
But i don't agree with your second point. Views offers two types of Any strings: < Any > and - Any - So if a user translates the any string, he'll first choose the type ( < > brackets or - - dashes) and he'll then go to admin/build/translate and search for the string and translate it. The < Any > string can anyway only be translated with spaces between the brackets and the string.
If the brackets or dashes will be hard coded, users will get a problem when they have also exposed filters not using hierarchical select. In this case they have to translate "- Any -" with "Tout" for example in french. The will receive "- Tout -" in the HS form and only "Tout" in the standard exposed views form.
Comment #6
Wim LeersIt'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
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'.
Comment #7
no2x CreditAttribution: no2x commentedOk, you're right ;)
So here's the next version of the patch. It doesn't work with FALSE, only with the 'old-any'. sorry i have no clue why.
Comment #8
Wim LeersAh right, it totally makes sense that it must use 'old-any'. My bad. Patch looks flawless now. Will commit tomorrow :)
Comment #9
Jolidog CreditAttribution: Jolidog commentedHello, 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!
Comment #10
no2x CreditAttribution: no2x commentedhi Jolidog,
i thought the same when i did the first version of the patch (see #3). Your v3 patch is about the same as the v1 patch.
But as discussed in #5 or #6 it should not be like that as it is a views problem. Only the Any should be the translateable string.
Comment #11
Jolidog CreditAttribution: Jolidog commentedSorry, 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:
Both options are translatable in HS and views is the faulty one.
What do you think?
Comment #12
lameei CreditAttribution: lameei commented+1
Comment #13
arski CreditAttribution: arski commentedhey, so whats the status of this? which patch is kind of "supported" and what are the chances of seeing this committed soon? Thanks!
Comment #14
arski CreditAttribution: arski commentedbump :) anything?
Comment #15
arski CreditAttribution: arski commentedUmm, 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!
Comment #16
Wim LeersThanks for the reviews!
Committed: http://drupal.org/cvs?commit=412136