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.

#1 synonyms.patch8.03 KBcatch
Passed: 13966 passes, 0 fails, 0 exceptions View
remove_synonyms.patch8.33 KBcatch
Failed: Failed to apply patch. View
Members fund testing for the Drupal project. Drupal Association Learn more


catch’s picture

Status: Needs work » Needs review
8.03 KB
Passed: 13966 passes, 0 fails, 0 exceptions View

Taxonomy fields patch took a long time to get in. Last ditch effort to get this in.

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community

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

Dries’s picture

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

Xano’s picture

Can Field API replace synonym collapsing? If no, -1, of yes, +1 (but I will still hate you).

catch’s picture

You should be able to provide a 'synonym' field, and then a field widget which does the collapsing.

Anonymous’s picture

For this feature to be implemented with Field API, the following needs to happen.

  1. Create a new text field. Cardinality unlimited.
  2. Add this field to any vocabulary where you want synonyms.
  3. Create a new widget whose validate and autocomplete properties are similar to the current autocomplete widget but do additional searches on the instance values of the synonym text field.

Rough sketch...

NikLP’s picture

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

Anonymous’s picture

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

catch’s picture

Translation of synonyms would be possible with translatable fields, if moved to a text field. Not easily with the current core code though.

NikLP’s picture

Shouldn't it all be translatable? Was it before?

What the hell are collapsible synonyms? :)

catch’s picture

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

moshe weitzman’s picture

I'm fine with this too.

NikLP’s picture

I 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?)


Anonymous’s picture

They should be fields, I agree. But nobody made a patch. They don't just fieldify themselves by force of will!

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Hopefully an alternative implementation leveraging Field API will emerge.

NikLP’s picture

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

Status: Fixed » Closed (fixed)

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

jhodgdon’s picture

Status: Closed (fixed) » Needs work

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

Anonymous’s picture

jhodgdon: 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.

catch’s picture

Status: Needs work » Closed (fixed)