Posted by miro_dietiker on January 18, 2010 at 11:36pm
2 followers
Jump to:
| Project: | Tagging |
| Version: | 6.x-1.x-dev |
| Component: | UX / GUI / Interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Hi Eugen! This tool looks awesome.
However it might be very helpful tu also support i18ntaxonomy extension (reduce tags/suggestions to a certain language) and i18nstrings (localize tags if needed).
Comments
#1
Hi Miro,
whats missing, what do we need? Never used that module.
I mean it must be a kind of translation layer, where terms get translated before there get shown to the user. But to they also got to be translated back? So, lets say german.
You currently view 5 translated Tags and now add "Auto". Should it the be translated back to car and then land in the backend? Or is the user responsible to post english-terms only (as in nearly all other approches)
#2
There are different approaches to setup a specific taxonomy.
Either you set it to LOCALIZABLE which results in passing terms through tt() before display (but primary terms are getting stored in "default" language without associated language information. (all languages have the same set of terms)
Or you set it to TRANSLATEABLE where all terms have additional language column and which results in capability of having different terms per language (providing a term translation set to group term identity of different languages - meaning direct translations). So if you edit a node in language X you should reduce term suggestion to language X or neutral instead of providing all languages.
However if language is not locked on a node edit form this can soon become a real mess (changing language of node, having presentation language, ..) here also things go wrong in current implementation of i18ntaxonomy (which should get fixed too!). Also i18ntaxonomy support is kinda limited but still usable. (not locking node language means you'd need to do some ajax update in case of language switch - which is currently completely missing... it's very strange to have assigned tags with language=german after changing a node language to english.)
But if you set node language to locked state the situation should be pretty stable and it's a good idea to limit to current language.
In a real multilingual environment we need to care about term language.
You may help me fixing the i18ntaxonomy issues and improve the situation in general to finally provide advanced multilingual tagging.
#3
Well, sound absolutely reasonable.
We should make this completely plugable, so provide alter methods after terms where taken out of the backend (with arguments like the current language) and later, a alter to change the terms before they get stored.
The implementation of how multilanguage terms should be in a other module then, like tagging_i18n .. where we grap those hooks / alter methods and build a bridge to i18ntaxonomy.
This way we can keep tagging slick in small while providing good extensibility. It is also possible to make tagging_i18n a submodule of course, to ease installation.
So iam interested, but i rather cant provide fixes for i18ntaxonomy, i simply got my "open source budget" tight to tagging, content_moderation and the new wysiwyg_imageupload which i will release in the near future.
But anyway i would help providing the API and helping implementing the tagging bridge.