Hello.
The function "glossify_nodeapi" contains the variable:
$pattern = '/\b(?<!\"|\/)' . $term . '\b/';
for matching. I changed this to
$pattern = '/\b(?<!\"|\/)' . $term . '\b/i';
to make it case insensitive. However, one of my node titles is "HTML", and when I made the regular expression case insensitive all **** broke loose, because my file extension is also "html"
This creates an output where one link is nested within the other, like this:
<a class="glossify_term" html.html="" directory_where_the_html_document_is_placed_virtually="" href="node-url.<a href=">HTML</a>
" class="glossify_term">node title
Comments
Comment #1
jponch commentedNot sure if this is the same problem or not, but I think there needs to be a UI setting for whether glossify should search in a case sensitive manner or not. On my site, I've found that if the word begins the sentence or happens to be capitalized in my content then it will not be glossified if the glossary term is not capitalized (and vise versa). Is there a work around for this?
Comment #2
talatnat commentedThere should a be a note about case-sensitivity in at least the Readme.txt. I spent a good bit of time troubleshooting my setup until I tried case-sensitive matches and got the module working, and then ran across this thread. I am doing the Links style, and it just does not look correct to have the Title in lower case to make this module work because most of all the content to be linked happens to be in lower case.
Glossary (the other module) has a UI setting for setting case sensitivity.
Comment #3
rsvelko commentedWe have:
1. Case sensitivity setting feature request - a new checkbox
2. A bug because glossify 1.x replaced even into html-tags - where it shouln't
With v.2.0 , released this night 2. is being fixed, so I make this a feature request.
Comment #4
Anonymous (not verified) commentedI would simply like to second the request for case-sensitivity options. It would also be helpful to have some transliteration functionality as well—there is a transliteration module. You can't expect users to always use the appropriate accent marks :)
Transliteration may somehow be linked with synonym functionality as well. Say, if the term has some automatically generated synonyms. This could cause some duplicate uses though, e.g. basé would transliterate into base, so I'm sure this would need to be a UI option.
Comment #5
shunshifu commentedsubscribing.
This is an awesome concept. But really needs case insensitivity to be useful.
Can't wait
Thank you
Comment #6
Ivo.Radulovski commentedinteresting
Comment #7
rsvelko commentedthis is simple enough to enter before 2.0 stable is ready...
Comment #8
rsvelko commented--------------------
"This creates an output where one link is nested within the other" - this was fixed in 2.0-rc2.
---------------------
case sensitivity will be in - when rc3 comes (actually rc-s are not meant for new features, but this one is very small )
Comment #9
Tong commentedit seems in latest release no checkbox: Case sensitve ?
where i can change manually function "glossify_nodeapi" in drupal ?
Cheers, Tong
Comment #10
okokokok commentedI added a little i to __glossify_convert_string_array_to_array_of_escaped_regexps()
Like this lower case terms are also glossified, but they're also turned into Uppercase. So it needs more work than the little i.
Comment #11
artatac commentedsub
Comment #12
WorldFallz commentedunsupported version, and the 6.x-3.x version has a case sensitivity setting