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.
Comment | File | Size | Author |
---|---|---|---|
#35 | i18nviews_includes_tid_depth.patch | 1.9 KB | anrikun |
#28 | 947468.patch | 7.38 KB | dawehner |
#24 | i18nviews_947468_24_taxonomy_arg.patch | 6.21 KB | miro_dietiker |
#19 | argument_validator_2.patch | 5.17 KB | iamjon |
#19 | filter.jpg | 4.1 KB | iamjon |
Comments
Comment #1
miro_dietikerWe 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 ;-)
Comment #2
iamjon CreditAttribution: iamjon commentedHi 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.
Comment #3
iamjon CreditAttribution: iamjon commentedI think this one sucks, but less
Comment #4
iamjon CreditAttribution: iamjon commentedyea the last one didn't suck less. eventually I'll get there.
Comment #5
miro_dietikerYour 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?
Comment #6
iamjon CreditAttribution: iamjon commentedHi 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?
Comment #7
miro_dietikerWell 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.
Comment #8
iamjon CreditAttribution: iamjon commentedI'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
Comment #9
iamjon CreditAttribution: iamjon commentedOne 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.
Comment #10
iamjon CreditAttribution: iamjon commentedThere'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
Is that bad?
I ran it through coder and it didn't yell at me.
All the best
Comment #11
iamjon CreditAttribution: iamjon commentedComment #12
miro_dietikerIt is very important that we detect the taxonomy mode correctly.
Both ways are right -- depending the taxonomy mode.
Sample from i18ntaxonomy:
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?
Comment #13
iamjon CreditAttribution: iamjon commentedI'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?
Comment #14
iamjon CreditAttribution: iamjon commentedmiro_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?
Comment #15
miro_dietikerAs 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.
Comment #16
bohz CreditAttribution: bohz commentedHI!
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
Comment #17
benklocek CreditAttribution: benklocek commentedWhat 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.
Comment #18
benklocek CreditAttribution: benklocek commentedI've just run into a bug also: Sometimes the validator settings are not saved when I use Term ID instead of Term Name.
Comment #19
iamjon CreditAttribution: iamjon commented@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?
Comment #20
iamjon CreditAttribution: iamjon commentedComment #21
Sylvain_G CreditAttribution: Sylvain_G commentedSubscribe
Comment #22
miro_dietikerDuplicated by:
#887720: Term translation not working
Comment #23
miro_dietikerDuplicated (?) by (or at lead related to):
#870670: Breadcrumbs generated from 'Taxonomy: ID' argument are not properly translated using i18n
Comment #24
miro_dietikerI 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.
Comment #25
iamjon CreditAttribution: iamjon commentedI 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...
Comment #26
miro_dietikerOK, thank you, fixed. Happy to see this in our project.
Now it's up to dereine to provide a views 3 port, as promised.
Comment #27
dawehner.
Comment #28
dawehnerHere 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!
Comment #29
miro_dietikerGreat, 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! :-)
Comment #31
simon_s CreditAttribution: simon_s commentedIn 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?
Comment #32
simon_s CreditAttribution: simon_s commentedOk, 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!
Comment #33
mandreato CreditAttribution: mandreato commentedSorry 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)".
Comment #34
miro_dietikerI 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 ;-)
Comment #35
anrikun CreditAttribution: anrikun commentedHere is a very simple patch that works for me.
It adds the missing Term ID (with depth).
Comment #36
mandreato CreditAttribution: mandreato commentedPatch #35 does function for me (after all caches flush).
Thank you very much anrikun !
Please commit this to 6.x-3.x-dev.
Comment #37
anrikun CreditAttribution: anrikun commentedYes 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?
Comment #38
mandreato CreditAttribution: mandreato commentedYes it does: I've applied manually on 6.x-3.x-dev
Comment #39
anrikun CreditAttribution: anrikun commentedGreat! Then could you reroll a patch for 6.x-3.x-dev?
Could someone review it on 6.x-2.x-dev too?
Comment #40
mandreato CreditAttribution: mandreato commentedEhm... 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 ?
Comment #41
simon_s CreditAttribution: simon_s commented@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!
Comment #42
anrikun CreditAttribution: anrikun commentedComment #43
miro_dietikerCommitted.
Note that there should be a vid check and only a translation call if translateability / lookups should be disabled in any other case.
Comment #44
mandreato CreditAttribution: mandreato commentedExcuse 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.
Comment #45
anrikun CreditAttribution: anrikun commented@mandreato: this issue is marked as fixed so please post #44 as a separate new issue.
Comment #47
miro_dietikerAs of shadysamir, the patch was not applied to 6.x-3.x.
#1389422: Translate Taxonomy Term Argument for Views 3
Comment #48
shadysamir CreditAttribution: shadysamir commentedTo 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.
Comment #49
adshill CreditAttribution: adshill commentedIs 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?
Comment #50
letrotteur CreditAttribution: letrotteur commentedReally need Translate Taxonomy Term Argument for 7.x! Any plan to port this any time soon?
Comment #51
mist CreditAttribution: mist commentedSame here, I can anyone please help with this bug ? I need use localized taxonomy term as argument.