Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I would like to sort ascending translated terms of taxonomy.
I couldn't find the field "Taxonomy term: Name (translated)" in the criteria sorting list.
Any solution or workaround?
Or is that a "feature request" issue?
Comment | File | Size | Author |
---|---|---|---|
#32 | i18nviews-sort-by-localized-name-1645304-32.patch | 3.6 KB | devad |
#13 | i18nviews-sort-by-localized-name-1645304-13.patch | 3.63 KB | jgullstr |
Comments
Comment #1
rondev CreditAttribution: rondev commentedIt is an Internationalization Views related issue. And I found the following comment in code:
// TODO currently almost impossible, JOIN to i18n_string table needed
/*
'sort' => array(
//'handler' => 'views_handler_sort',
'handler' => 'i18nviews_handler_sort_taxonomy_term_name',
),
*/
:-(
Comment #2
rondev CreditAttribution: rondev commentedChange project issue list.
Can we hope this can be solved? Which is the limitation, Drupal core, Views?
Comment #3
Cyclodex CreditAttribution: Cyclodex commentedI am also interested and willing to help fix this issue.
I just fixed something similar for my exposed filters in views : #1312074: Sort exposed translated filters by their value.
Comment #4
liquidcms CreditAttribution: liquidcms commenteduntil this gets fixed; a PHP Sort can do the trick quite nicely.
Comment #5
filburt CreditAttribution: filburt commentedWorks perfectly - thanks!
Filburt
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedViews does come with the ability to display rendered taxonomy terms now (at least in 3.5, dunno when it was introduced). However, the sort handler for ordering by translated taxonomy terms is still missing. For those who find this thread (like me) and only wanna sort by translated taxonomy term (aka rendered), I have made a feature request here: http://drupal.org/node/1866000 - because I think this rather belongs into views. Correct me if I am wrong :-)
I hope this is moving forward a little, since all published work-arounds don't work for me.
Cheers,
Stephan
Comment #7
joel_osc CreditAttribution: joel_osc commentedFYI - entity translation has gone beta recently and everything works in views much better - including sorting.
Comment #8
rondev CreditAttribution: rondev commentedI just installed Entity Translation for ability of per exemple translating captions of media images. It works well and I'm very happy with that. Moreover it will probably be upgradable to D8 as it seems to be the future. I was thinking to change to Entity Translation for taxonomy too.
I will do on a test site. But I think at the moment there could be issues with xmlsitemap, ... I will give some news when it is ready.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedHm... I fail to see how Entity Translation helps with the described taxonomy term sorting problem. Isn't Entity Translation not just for ... entities?
Comment #10
joel_osc CreditAttribution: joel_osc commentedEntity translation plus title module (which creates a replacement for the term name which is a field) means that a single tid will have a name_field for each language. So the term's name_field will be available to views in multiple languages. So a view showing name_field {not term name (translated)} will display two rows, one row for each language), add a filter for name_field (= user's current language) sort by name_field and your done. I think going forward entity translation is the way to go...it is much easier to manage translatable fields than two separate entities (node/term) and synchronizing common fields between them. Although, not all the corner cases have quite been worked out yet it Entity Translation is working quite well.
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commented@joel_osc Thanks for that explanation, I appreciate it. Looks like I'll have to play with it a little to find the 'right way'.
Comment #12
jgullstr CreditAttribution: jgullstr commentedTo be able to sort by translation, we need a join to the locales_target table, where the actual translations are stored. An intermediary join to i18n_string is needed to get the string ids. I've attached a handler that adds these joins and sorts by localized name.
As my experience writing views handlers is limited, I'm not sure that the use of "$this->table" is correct in this patch, or if some alias should be used. At the very least, this should be a good starting point for getting this issue fixed.
EDIT: Also, there is no fallback language in this patch, so terms lacking translations are not sorted at all. Should terms without translations be hidden or be "mixed in" sorted by default language? An option in the sort could be an idea?
Comment #13
jgullstr CreditAttribution: jgullstr commentedFor results not to go haywire when sorting using relationships, table alias needs to be used when available.
I'm not sure that I'm using the $base parameter correctly when adding the relationships:
I'd be grateful if someone could give a more verbose explanation of this part, and what repercussions may arise from using it incorrectly.
Corrected patch attached.
Comment #14
Adirael CreditAttribution: Adirael commentedPatch in #13 worked great for me.
Comment #15
devad CreditAttribution: devad commentedPatch in #13 works great for me as well (thanx), but for translated term names without relationship only (Do not use relationship).
It seems that if some relationship is selected filter doesn't apply.
I have a view with term-parent relationship grouped by parents.
I have added sort: (Parent) Taxonomy term: Name (translated) (asc)
But it sorts nothing.
Changing status to "needs work".
Comment #16
devad CreditAttribution: devad commentedPatch #13 works nice without relationship. So, maybe it's better to change status of this issue to "Reviewed & tested by community".
And "Sort by Taxonomy term: Name (translated) field WITH RELATIONSHIP" could be the following feature request.
Step by step...
Comment #17
jasom CreditAttribution: jasom commentedCode in #13 worked for me! One small note: you need to clear all caches after applying this patch. if you want to see "Taxonomy term: Name (translated)" option in views_ui.
Comment #18
jasom CreditAttribution: jasom commentedSolution in #13 still can be a little bit more perfect.
It sorts non-English characters at the end of regular-English character. For example "Š" (sharp S) should go after "S" not after "Z" (the last letter).
See the example here:
Transliteration module handle this for Pathauto and files uploaded to file system.
Special characters can be: Ř, Ľ, Č, Ž, Š, Ď, Ť, Ň...
Comment #19
jgullstr CreditAttribution: jgullstr as a volunteer commented@jasom,
As this patch sorts values in the database, the sort order is decided by the database collation, not the handler itself. By setting a proper collation, your list should get sorted correctly.
Comment #20
jasom CreditAttribution: jasom commented@jgullstr
Thanks for a hint. What do you mean by "By setting a proper collation"? Should I set something in database or in server?
Comment #21
jgullstr CreditAttribution: jgullstr as a volunteer commentedThe database collation is set per table in the database. For a list of available collations, see here. In your case, utf8_czech_ci would probably be the correct one. For how to change your current collation, see here.
You should also alter your settings.php, so new tables are created using the correct collation. The collation can be defined in the settings variable $databases as follows (assuming you use the default database):
IIRC, the preferred collation can also be set globally in your sql configuration, but you will still need to alter your existing databases.
Also, remember, at the very least, to backup your site before trying this. You are, after all, talking to a stranger on the internet :)
Comment #22
pixelpreview@gmail.com CreditAttribution: pixelpreview@gmail.com commentedfor a multilanguage site, I choose utf8_general_ci
I have 3 languages on my site : nederlands, french and deutch
I have a view with a sort on translated term name but in french that have accentued characters like 'éèà...' the order is not correct and same problems with uppercases
I have this for example
DUNE
dame
durant
défendre
départ
au lieu de :
dame
défendre
départ
DUNE
durant
Any idea to resolve this problem ?
Comment #23
jgullstr CreditAttribution: jgullstr as a volunteer commentedYou could always use collate in the query, thus determine language at run-time. This could be a good feature to add to i18nviews, to allow different sorting rules per language.
In the meantime, Here's one possible solution.
Comment #24
pixelpreview@gmail.com CreditAttribution: pixelpreview@gmail.com commentedwith your solution, my view renders no results. I see with a var_dump that the COLLATE is added to my order by
public 'orderby' => &
array (size=1)
0 => &
array (size=2)
'field' => string 'term_i18n_string_translation_translation COLLATE utf8_unicode_ci' (length=64)
'direction' => string 'ASC' (length=3)
but no results in any language I remove the collate and I have results :(
Comment #25
danon1981 CreditAttribution: danon1981 commentedI tried #13 but this gives me a Broken/missing handler when I add sort on translated term name
Comment #26
yang_yi_cn CreditAttribution: yang_yi_cn commentedone problem: If it's a single view used in multilingual site, English doesn't work, only the translated ones work. This kinda can be mitigated by adding both the translated handled and the default / non translated handles.
second problem: as people mentioned before, you need COLLATE utf8_general_ci to do sort in MySQL ignoring accents. However the `locales_target`.`translations` field is BLOB, which sorts by BINARY, so you need to do something like
ORDER BY CONVERT( `translation` USING utf8 ) COLLATE utf8_general_ci ASC
which I don't believe it's very easy to do in Drupal 7 dynamic query API, even if you can make it, probably breaks SQL compatibility as it's mostly MySQL only solution.So I think a better solution is just to override the templates and sort using php-intl extension's Collator function and sort the results in PHP.
Comment #27
jasom CreditAttribution: jasom commentedI have "Broken/missing handler" result too.
Comment #28
pmusaraj CreditAttribution: pmusaraj commented@jasom and @danon1981 I had the same issue after upgrading the module to the current version. I reapplied the patch at #13, cleared caches and the issue was automatically fixed.
Comment #29
devad CreditAttribution: devad commentedPatch #13 re-roll for latest dev
Comment #30
devad CreditAttribution: devad commentedI have tried to re-roll patch, but it seems that my windows environment broke something and it doesn't apply cleanly at simplytest.me. so, I'm hiding it from files list.
Comment #31
matthieu_collet CreditAttribution: matthieu_collet commentedthis doens't work with current version, I obtain "Broken / missing handler" and sorting doesn't work
anybody else tried with i18nviews 7.x-3.0-alpha1 ?
Comment #32
devad CreditAttribution: devad commentedPatch #13 re-roll for latest .dev
I have tested patch #32 at simplytest.me. It applies cleanly and works nicely for me.
More reviews are welcome...
So maybe we will have this committed... before new re-roll is needed. :)
Patch #32 can be tested both with alpha1 and current dev.
Comment #33
kienan CreditAttribution: kienan commentedlooks okay to me. applied and test on a site. I didn't do a full review, but it seems okay at a glance. marking rtbc
Comment #34
nironan CreditAttribution: nironan commentedWorked smoothly for me, thanks!
Comment #35
sthomen CreditAttribution: sthomen commentedI tried the latest patch, and it seems to sort terms with a missing translation first (null values first presumably), which is a bit of a problem.