Not displaying terms containing foreign characters

I'm not sure what you mean "doesn't recognize." I have a vocabulary with a term that starts with é and another with ñ and they show up fine - although to be in correct order, one must set the alphabet on the "Alphabet" settings tab. It may also require you to adjust the collation on the term_data table, as was reported some time ago, and is (partially) documented in http://drupal.org/node/201763.

One more question: Do these characters begin the term, or just somewhere else in them? ("école" as opposed to plissé)

It's kind of strange, because the 1.7 version was before most of the language support was added.

I just set up a test node, with "In order to test foreign language support, I have the words école, plissé, and ñachi in my glossary." and all the terms are flagged as they should be.

Well, let's deal with that last part first: http://drupal.org/node/239880 is fixed in the -dev version. Then there's also: http://drupal.org/node/233752#comment-793342

After midnight (GMT) tonight, download the -dev version, verify that you have acronym links styled visibly, save the settings again (even if no changes), and retry it.

Well, it's progress I guess. Can you see any kind of pattern to this? Can you tell me all your settings, please.

Wow, that is the oldest MySql I have ever seen! BTW, are you aware that 7.x will require PHP 5.2+ (probably at least 5.2.5) and MySql 5+. Time to pressure your host to upgrade.

I'll see if there's anything that stands out.

Well, one thing I see that has confused some people. You have "only first match" which means only the first occurrence in a node is flagged.

Another issue is discussing the problem of non-English characters. For example, "école" does not match "école" or "école".

Is the term (in the vocabulary) entered in exactly the same way that the word is typed in the content?

That sounds like a caching issue. Make sure you've cleared the cache_filter table.

Probably just documented better, because there are things like <pre> and <code> where the module should not be operating.

martig - were <pre> tags the only problem?

There's no reason to keep them hardcoded - someone may use them in another way (like here, it's not code-escaping, it's changing to a monospaced font) or just not use them to make the filter faster. Also we won't have to document it when it's there - just add an update and remove pre and code from $open_tags and $close_tags (lines 404-405).

/* Implementation of hook_update_N
 * We move the hardcoded tags to configurable Blocking tags
 */
function glossary_update_5103() {
  $ret = array();
  $result = db_query('SELECT format, name FROM {filter_formats}');
  while ($filter = db_fetch_array($result)) {
    $format = $filter['format'];
    $value = variable_get("glossary_blocking_tags_$format", NULL);
    if(!is_null($value)) {
      $value = "code pre $value";
      variable_set("glossary_blocking_tags_$format", $value);
    }
  }
  return $ret;
}

(The data's serialized, so we can't just make an UPDATE query). We need '<a ' because there's the space, we can document it with [code] right where [no-glossary] is mentioned.

Thank you , Marcin.

For those who don't know him, Marcin (mwrochna) is the person who did a significant rewrite on this module (for the GHOP season) that gives it the capability to skip parts of the content.

I will look at how to better document this.

Changing status so I'm reminded to fix it.

I just committed a fix to the form description and filter tips to mention these hard-coded tags.

I'm still thinking about moving those tags to the exposed list of blocking tags. Certainly it's easy enough, but I don't want to break the installation for those who are already using this module. So, I need comments, people.

I'm not sure I understand. It won't break anything if they run the update (and a red warning will remind them to). Setting $value = "code pre $value"; only adds those tags, nothing gets lost and the behaviour is exactly the same.
Just add glossary_update_5103() from #19 to glossary.install, change to $open_tags = array('[no-glossary]', '<', '<a ', '[code'); , $close_tags accordingly, and change defaults in variable_get()s from 'abbr acronym' to 'code pre abbr acronym'... or did I forget something?

You might be surprised how many people don't run update.php when updating modules. But you are right that the impact should be close to non-existent, but I would really like more eyes on this.

I think this sounds like it could be useful and people could at least have the option. Honestly, if people don't run update every time, then they should expect to have problems. It is written there to remind them.

So +1 from me.

Committed to both branches.