Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
All the same arguments as #526120: Remove related terms from core now that terms can have a term reference field. Patch won't work until taxonomy_autocomplete_legacy() is removed, which depends on term fields going in.
Comment | File | Size | Author |
---|---|---|---|
#1 | synonyms.patch | 8.03 KB | catch |
remove_synonyms.patch | 8.33 KB | catch | |
Comments
Comment #1
catchTaxonomy fields patch took a long time to get in. Last ditch effort to get this in.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedOh man. Xano is gonna hate us so much. He might never speak to us again.
This patch is all -'s no +'s. It's very very good.
Though we do mourn synonym collapsing.
Comment #3
Dries CreditAttribution: Dries commentedI'm comfortable removing this feature, but let's get some other people to comment on this too.
At the same time, I'm also comfortable leaving this feature in.
Either works for me.
Comment #4
XanoCan Field API replace synonym collapsing? If no, -1, of yes, +1 (but I will still hate you).
Comment #5
catchYou should be able to provide a 'synonym' field, and then a field widget which does the collapsing.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedFor this feature to be implemented with Field API, the following needs to happen.
Rough sketch...
Comment #7
NikLP CreditAttribution: NikLP commentedWhat Ben is saying sounds reasonable? I've only even used synonyms for hacks to be honest. I suppose the only thing that springs to mind should the term title accept the synonyms as well, or do they need to be different fields? I they're *truly* synonymous, should we not be able to reorder them so that the top one is the "primary" synonym? That might be nonsense, I don't know. Just thinking out loud.
Again on that note, are there any implications with i18n and synonyms or is that a non-issue at this point?
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commented@niklp Term synonyms are effectively term title synonyms. SKOS (for example) has different properties: label (term title) and altLabel (term synonym). I don't know what might be gained by merging these into the same field where delta 0 is the authoritative term name.
There are all kinds of i18n issues here, but I don't know if they're complicated or what.
It's also worth mentioning that until about 2 weeks ago, Taxonomy term synonyms meant something in D7. Xano had brought synonym collapsing into core, but this was before the purge of non-field api code from taxonomy.module. So we have lost something, but most users hadn't been aware that we gained it.
Comment #9
catchTranslation of synonyms would be possible with translatable fields, if moved to a text field. Not easily with the current core code though.
Comment #10
NikLP CreditAttribution: NikLP commentedShouldn't it all be translatable? Was it before?
What the hell are collapsible synonyms? :)
Comment #11
catchSynonym collapsing means that if you tag something with a synonym of an already existing term, it'll swap it in for that term instead of creating a new one. So if I have "United Kingdom" as a term, and "Great Britain" and "UK" as synonyms, things will only ever get tagged as "United Kingdom" instead of creating three separate terms.
Translatable - in D6 terms aren't translatable except for using i18n.module. Hopefully they'll be at least partially translatable in D7, although not everything (term name and description) got converted to fields for that to be as easy as it might have been.
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commentedI'm fine with this too.
Comment #13
NikLP CreditAttribution: NikLP commentedI think the collapsing wotsit sounds like a GREAT idea - should be there by default, it's a common sense feature IMO.
I'll buy Xano a beer if he reworks the patch onto this :)
Whoa, term name and description aren't fields?? That's news to me. What's stopping that show? That's something that I thought would be default in D7 too - forgive me if I'm late to the party, I thought that was the point (or am I missing the point?)
END_CLICHE_EXPLOSION
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedThey should be fields, I agree. But nobody made a patch. They don't just fieldify themselves by force of will!
Comment #15
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Hopefully an alternative implementation leveraging Field API will emerge.
Comment #16
NikLP CreditAttribution: NikLP commentedWell I have beer, but not the ability to suddenly realise something isn't done and then magically develop the skills to rewrite big chunks of taxonomy.module using field api which I've never even seen before, notwithstanding the fact that my coding abilities are pretty basic anyway, deep breath. :)
Maybe Xano can continue his work and see what happens. I sort of have a feeling that if nice patches appeared they might get into core anyway...
Comment #18
jhodgdonIs there an upgrade path from D6 to D7 for this? Just asking... Please close this up if there is (or if that is a separate issue), but I sure didn't see one in the patch, and it seems like anyone who upgrades from D6 to D7 with a vocabulary that contained synonyms is just going to lose all that information?
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commentedjhodgdon: Upgrading to Drupal 7 will not drop the term_synonym table. It will be contrib's responsibility to provide the upgrade path, but the data won't be deleted and it will still be usable.
Comment #20
catch