I have a view that gets a taxonomy term as the argument.
I want www.example.com/en/course-list/Thistag to return all the english courses that have been tagged with 'Thistag' and
www.example.com/fr/course-list/Cettetag to return all the french courses that have been tagged with 'Thistag' (This tag is translated as Cettetag )

I figured out how to do it by creating new handler. My handler is right now is very specific to the site I'm working on but I'll post anyway so maybe together we can figure this out.

I have no idea how to alter the form so that has a check says term is localized...and there should probably be a condition there somewhere for what to do if the argument is not localized.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

miro_dietiker’s picture

We just ran into an almost similar issue when missing an argument title (%1) to display translated although i18nstrings (term localization) was defined.

It seems either a handler needs to be implemented as suggested -- with the issue that handlers with different extensions are incompatible due to mutual overrides -- or we need to reimplement the title handling to correct it.

Pity, both seems hackish to me regarding clean further extensibility.

In our project we finally set the title in the theming layer. If we can't find a clean solution, even the ugliest solution is good enough ;-)

iamjon’s picture

FileSize
6.63 KB

Hi miro_dietiker,
I talked to dereine today on mirc...so yea I have absolutely no justifiable reason for doing it the way I did, I'm reattaching my attempt this time with overriding the taxonomy term validator.

iamjon’s picture

FileSize
8.38 KB

I think this one sucks, but less

iamjon’s picture

FileSize
1.86 KB

yea the last one didn't suck less. eventually I'll get there.

miro_dietiker’s picture

Your editor wrongly introduced tabs... Additionally the code has trailing spaces.
Please use coder.module to check code you create to succeed satisfy standards.

Your last patch doesn't contain any validator code...

Could you please create a new patch that contains the right code to be reviewed?

iamjon’s picture

Hi Miro, I'm going to paste an update soon,
My plugin wasn't being called at all, now that it is fixed I need to see what I can come up with.
do you think this is a duplicate of #832100: Taxonomy term argument validator should not validate terms defined in other languages?

miro_dietiker’s picture

Status: Active » Needs work

Well looks for me like "different issue -- same solution" ;-)
Possibly somehow partial duplicate...

At least i kindly ask you (both threads) to provide a clean patch to test and include ASAP.

iamjon’s picture

I'm working on it right now. Hopefully you'll be on irc to discuss it with me.
Patch is on the way, I'll clean it up once I get it work.
Best regards

iamjon’s picture

FileSize
12.26 KB

One of the things I noticed is that the other method assumes that term has a language assignment. My way of doing it uses 18n to find the source. Pic attached.

iamjon’s picture

FileSize
5.76 KB

There's still some stuff that needs to be done like acknowledging the different approach taken by #832100: Taxonomy term argument validator should not validate terms defined in other languages as well as I got rid of the tid by default part of the original class

'#default_value' => isset($this->argument->options['validate_argument_transform']) ? $this->argument->options['validate_argument_transform'] : FALSE,
$type = isset($this->argument->options['validate_argument_type']) ? $this->argument->options['validate_argument_type'] : 'tid';

Is that bad?
I ran it through coder and it didn't yell at me.
All the best

iamjon’s picture

Status: Needs work » Needs review
miro_dietiker’s picture

It is very important that we detect the taxonomy mode correctly.
Both ways are right -- depending the taxonomy mode.

Sample from i18ntaxonomy:

switch (i18ntaxonomy_vocabulary($vocabulary->vid)) {
  case I18N_TAXONOMY_LOCALIZE:
...
  case I18N_TAXONOMY_LANGUAGE:
...
  case I18N_TAXONOMY_TRANSLATE:
...
}

i18ntaxonomy does the mode detection on many code positions. The solution witout case detection is not general enough and wrong for many not-like-you cases.

Could you please update the code for those two cases?

iamjon’s picture

I'm trying to figure out where I can get that info efficiently.
The stuff that I basically ignored and didn't copy from the parent class is that bad?

iamjon’s picture

miro_dietiker,

I think there is something that I'm missing.

I created a one vocab of the three options given to me by i18.
The first I took a term and translated it. If I give the translated term as the argument it works.

The second a created with term per language. added the same term to both languages. It worked

The third I created two separate vocab assigned each to a language added a the same term to both languages. It worked.

The only thing I can added in my filter settings I set it to current user language.

I don't mind creating the checker, although I might need some hand holding. But what am i checking for?

miro_dietiker’s picture

Status: Needs review » Needs work

As of my quick thoughts:
You should try to localize terms only if the vocabulary is in LOCALIZE mode. Deactivate i18nstrings() calls in all other cases.
In TRANSLATE case you should apply language condition in the (sql) lookup to match the current language.

Load the vocabulary mode using the views settings (with given vid) and check for it.

bohz’s picture

HI!
using views and i18nviews 3.x-dev latest versions here.
I have my taxonomy set as TRANSLATE case and the argument gets translated correctly only with default taxonomy path (taxonomy/term).
When I override the vocab path with taxonomy_redirect, the argument doesn't translate.

for example, if term/2 is the translation of term/1:

1. with a view overriding the default taxonomy path:
taxonomy/term/1 --> (change language) --> /en/taxonomy/term/2 [correct]

2. with the same view but with custom path (set from taxonomy redirect)
category/item/1 --> (change language) --> /en/category/item/1 [not correct]

other taxonomy related modules, namely taxonomy menu, respond correctly and change accordingly with the language; it seems that the translation of the views argument is somehow tied to the default taxonomy/term path.

I am now about to test the suggestions from this thread in order to solve my problem
I also need to check if the depth modifier may be related to this.

meanwhile, any other suggestion is welcome.

Thanks a lot

benklocek’s picture

What are the Views validator settings you need to have to get this to work?

I have TermID > Taxonomy Term, Argument Type Name/Symonym converted to ID.

And it does not seem to be working. I get no results back when using the translated term.

UPDATE: Nevermind, after looking at the code, I figured it out. You will see a new option under the "Validator" fieldset on the argument, "Localized Taxonomy Term Validator".

Woohooo! It works! Although my argument Title is in the default language, and not the selected language.

benklocek’s picture

I've just run into a bug also: Sometimes the validator settings are not saved when I use Term ID instead of Term Name.

iamjon’s picture

Status: Needs review » Needs work
FileSize
4.1 KB
5.17 KB

@miro_dietiker,
I tried a different approach, i limited the vocabs only the the ones that have been localised.
Using the filter that comes with views basically takes care of the second option unless there is something that I'm missing screenshots and patch attached.

@benklocek,
I didn't check for term id in my patch because I figured "hey we already have the id"...but maybe I should...

@bohz
I'm sorry I have no clue, I haven't used views 3 yet.

I still have to run it through coder.
I only checked with node listings, should this work for term listings as well?

iamjon’s picture

Status: Needs work » Needs review
Sylvain_G’s picture

Status: Needs work » Needs review

Subscribe

miro_dietiker’s picture

miro_dietiker’s picture

miro_dietiker’s picture

I worked some time on this and..
- checked functionality and edge cases
- cleaned code up
- fixed default value issues in validator options
- fixed process issues on validator options
- renamed the i18 to i18n
- added title argument localization which was missing
- added limitation ToDo text which also applies to i18ntaxonomy core

Note that due to the rename you need to readd/reconfigure your current i18n term validators.
It seems to me this can be committed to i18n as is. Someone please confirm.

Note: Dereine states this needs a rewrite von 6.x-3.x.

iamjon’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm that it works.
The only thing to add is a space on line 95
$localised =db_fetch_objec...
should be $localised = db_fetch_objec...

miro_dietiker’s picture

Version: 6.x-2.x-dev » 6.x-3.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

OK, thank you, fixed. Happy to see this in our project.

Now it's up to dereine to provide a views 3 port, as promised.

dawehner’s picture

Assigned: Unassigned » dawehner

.

dawehner’s picture

FileSize
7.38 KB

Here is a first version without any test.

I would have named "views_plugin_argument_validate_i18n_taxonomy_term" "i18nviews_plugin_argument_validate_i18n_taxonomy_term".
The views3 code looks much nicer!

miro_dietiker’s picture

Status: Patch (to be ported) » Fixed

Great, dereine.
Committed the name change in 6.x-2.x. I was a little confused. Thx.

Also committed the corresponding 6.x-3.x version.
(In addition i renamed a different handler too in 6.x-3.x version.)

Happy to closing this issue now! :-)

Status: Fixed » Closed (fixed)

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

simon_s’s picture

Version: 6.x-3.x-dev » 6.x-2.x-dev

In the 6.x 2.x dev from dec-28 the translation of argument terms in views titles is not working. Wasn't the argument translation patch committed?

simon_s’s picture

Assigned: dawehner » Unassigned

Ok, I just noticed that argument translation is only not working with argument "Term ID (with depth)".
The basic argument Term ID translation works.
Could you please check this and also make it compatible to "term ID (with depth)"?

Thanks in advance!

mandreato’s picture

Status: Closed (fixed) » Active

Sorry to reopen, but I confirm that on 6.x-3.x-dev the translation does function only for "Term ID" and not for "Term ID (with depth)".

miro_dietiker’s picture

I don't think there's code that tries to cover this case currently. This case is much more complex i think.

I don't know if this can be fixed cleanly in 6.x-2.x without side effects (hitting other modules).
Someone need to take a bunch of time and look into this in depth.

Awaiting patches ;-)

anrikun’s picture

Status: Active » Needs review
FileSize
1.9 KB

Here is a very simple patch that works for me.
It adds the missing Term ID (with depth).

mandreato’s picture

Patch #35 does function for me (after all caches flush).
Thank you very much anrikun !
Please commit this to 6.x-3.x-dev.

anrikun’s picture

Yes you're right: cache flush is required after patching.
The patch is for 6.x-2.x-dev.
I don't know about 6.x-3.x-dev. Does it work on 6.x-3.x-dev too?

mandreato’s picture

Yes it does: I've applied manually on 6.x-3.x-dev

anrikun’s picture

Great! Then could you reroll a patch for 6.x-3.x-dev?

Could someone review it on 6.x-2.x-dev too?

mandreato’s picture

Ehm... I've never learned how to build patches...
Could be a problem if I simply attach here the original file from 6.x-3.x-dev and my manually patched version ?

simon_s’s picture

@Miro:
Could you please commit the patch of anrikun (#35) to the current devs of 2.x and 3.x? Otherwise we may loose this useful feature after the next module update...

Thanks a lot!

anrikun’s picture

Status: Needs review » Reviewed & tested by the community
miro_dietiker’s picture

Status: Reviewed & tested by the community » Fixed

Committed.

Note that there should be a vid check and only a translation call if translateability / lookups should be disabled in any other case.

mandreato’s picture

Excuse me, but line 23 of i18nviews_handler_field_term_node_tid.inc should also include the following order by clause (in bold):

$result = db_query("SELECT tn.vid AS node_vid, td.*, v.name as vocabulary FROM {term_data} td INNER JOIN {term_node} tn ON td.tid = tn.tid INNER JOIN {vocabulary} v ON v.vid = td.vid WHERE tn.vid IN (" . implode(', ', $vids) . ")$voc ORDER BY v.weight, td.weight, td.name");

Because the list of terms from different vocabularies should list ordered by those vocabularies weight.

anrikun’s picture

@mandreato: this issue is marked as fixed so please post #44 as a separate new issue.

Status: Fixed » Closed (fixed)

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

miro_dietiker’s picture

Version: 6.x-2.x-dev » 6.x-3.x-dev
Status: Closed (fixed) » Needs work

As of shadysamir, the patch was not applied to 6.x-3.x.
#1389422: Translate Taxonomy Term Argument for Views 3

shadysamir’s picture

To be more specific. Patch from #35 never made it to 6.x-3.x. Term ID does work for 6.x-3.x but not Term ID with depth.

adshill’s picture

Is there any chance of this making it into 7.x? I can't localise the %1 arguments using the D7 version and I'm assuming this would fix it?

letrotteur’s picture

Really need Translate Taxonomy Term Argument for 7.x! Any plan to port this any time soon?

mist’s picture

Same here, I can anyone please help with this bug ? I need use localized taxonomy term as argument.