Add a hook to allow other modules to alter the list of glossary terms

Patch doesn't work for me, I get an error about passing an array by reference in your additions - it seems like the $context vars in drupal_alter() are to be passed by reference. I re-rolled a new patch changing your additions to:

  drupal_alter('glossify_terms', $terms, $filter, $langcode);

and the alter function is now useable.

I really like this idea and agree with #4. I'll try to reroll the patch with an array this weekend if someone doesn't get to it sooner.

Thanks for a great idea/patch!

Ran into another issue implementing an entity_translation helper module like the one mfb describes in the OP. Basically, the l() function call in theme_glossify_links() isn't language aware, so it can only create links to a term with the default language.

I have a solution that builds on my last patch that works like so:

1) Passes $langcode down into theme_glossify_links()
2) Loads a $language object based on the passed in $vars['langcode'].
3) Passes $language into l() so it can build multilingual links.

Should this work all be rolled into one patch or should I open another issue?

Either way, here's a patch to address #4.

And here's a patch to add language support to the theming function. Let me know if it should have its own issue.

Apply the patch from #7 and then this one.

Haven't split the theming patch out, I'll get around to that soon. :)

One additional issue I'm having with this is that the $terms array doesn't consist of "real" $term objects. If I want to do additional transformations, I have to load in the extra term data myself. It seems as though calling taxonomy_term_load() from an implementation of hook_glossify_terms_alter() cause drupal to hang. I've worked around by doing direct sql queries on my tables, but I think it would be best to have access to actual term objects here.

I haven't looked too much at how best to do this, but I see the glossify terms are loaded directly via sql instead of using taxonomy_term_load(). Would it be possible to implement taxonomy_term_load() instead and stuff the relevent glossify data in $term->glossify instead?

Added a new issue + patch for #8 / glossify-theme-language-links.patch here:

https://www.drupal.org/node/2359887

This last patch may have been patched against the beta, not the dev version. I'll need to check (and re-roll if necessary) when I have a chance.

One part of this patch still needs a little work. The language detection shouldn't be in the theme function, it should be in _glossify_to_links() like so:

  if (trim(empty($langcode)) || $langcode == 'und') {
    $language = language_default();
  }
  else {
    $languages = language_list();
    $language = $languages[$langcode];
  }

This way it'll A) still get the correct language if the theme function is overridden and B) will fall back to the default site language if there is no langcode or it is 'und'.

@#13 -- has been fixed with #2375501: Protect against recurision.

I'd like to get this added along with fixing #2359887: Pass language object to theme_glossify_links() to allow for multilingual paths to terms but would prefer to handle them separately. However, this patch is passing $langcode. Does it rely on having the language code patch done first? And is https://www.drupal.org/node/2359887#comment-9265361 the correct patch to apply (i can adjust it if it was rolled against beta, I just want to make sure I use the correct patch.

and thanks for working on this! i have no multi language sites and no need for them, so it's difficult for me to carve out time to work on language issues.

For this issue, #7 should be the correct patch. For the theming issue, this patch should be: https://www.drupal.org/files/issues/glossify-theme-language-links_0.patch. Sorry for the sloppiness, was working under deadlines but wanted to contribu back. :) Does that answer your question?

I also have a multilingual helper module (I need to update this a bit still) that can stand on its own, but it might be helpful to fold into glossify for better multilingual support out of the box.

Hello, I'm finally getting around to look at the latest dev release. It looks like most of the changes made it in but this one's not there yet. Do you need anything else from me to get this working in a release?

I'd like to make an actual project of glossify_entity_translation, but won't until there's a working release - for the time being it'll only work with my patched module. :)

Thanks!

Sorry, I must have missed your latest comment! I'm hoping to have time this week to get this updated with as much of the remaining issues as I can.

And if your glossify_entity_translation module is only for glossify, I'm happy to consider adding it to the module directly or as a submodule. Post a zip if you're interested and I'll take a look. IMO it doesn't usually make sense to have such module specific code have to live in a separate project.

Hey, thanks for getting back so quickly! My module uses the hook patched in from this issue, and is available here:

https://www.drupal.org/sandbox/molenick/2343783

I think it also depends on the "name_field" module but I don't have it listed as a dependency. I don't recall 100% right now, but I think that is needed to allow for entity translation of the term title.

Patch from #7 working fine with dev version.

Integration with the synonyms module like the OP mentioned would be really super awesome :)

If the patch in #7 is a starting point for that, I wonder what it would take to achieve this...? http://cgit.drupalcode.org/sandbox-molenick-2343783/tree/glossify_entity... looks like it didn't have to do too much to alter the glossify terms... I wonder if altering for use with synonyms would be similar in scope?

Drupal 7 is EOL.