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?



rondev’s picture

Status:Active» Closed (won't fix)

It 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',

rondev’s picture

Project:Views» Internationalization Views
Version:7.x-3.3» 7.x-3.x-dev
Component:taxonomy data» Code
Status:Closed (won't fix)» Active

Change project issue list.

Can we hope this can be solved? Which is the limitation, Drupal core, Views?

Cyclodex’s picture

I 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.

liquidcms’s picture

until this gets fixed; a PHP Sort can do the trick quite nicely.

global $language;
$term1 = i18n_taxonomy_term_name(taxonomy_term_load($row1->tid), $language->language);
$term2 = i18n_taxonomy_term_name(taxonomy_term_load($row2->tid), $language->language);
if (
$term1 > $term2) return 1;
else return -
filburt’s picture

Works perfectly - thanks!


rickauer’s picture

Views 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.


joel_osc’s picture

FYI - entity translation has gone beta recently and everything works in views much better - including sorting.

rondev’s picture

I 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.

rickauer’s picture

Hm... I fail to see how Entity Translation helps with the described taxonomy term sorting problem. Isn't Entity Translation not just for ... entities?

joel_osc’s picture

Entity 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.

rickauer’s picture

@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'.

jgullstr’s picture

Category:Support request» Feature request
Issue summary:View changes
Status:Active» Needs review
new3.49 KB

To 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?

jgullstr’s picture

new3.63 KB

For 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:

$base: The name of the 'base' table this relationship represents; this tells the join search which path to attempt to use when finding the path to this relationship.

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.

Adirael’s picture

Patch in #13 worked great for me.