The transformation is applied in the wrong place: i.e. AFTER the term in the original language has been found.
But at that time, the search in the locales_target has already failed because the argument contains the dashes. Furthermore, if the query is successful, then the transform must not be applied another time.

The proposed applies the transform also in the localized search adding a new argument to the function i18nviews_locale_source.
Then, if the search is successful, put the transform flag to false, because we already have the term without the dashes.

See the attached patch.

NOTE: this patch already contains the one proposed in http://drupal.org/node/1786876

Files: 
CommentFileSizeAuthor
#1 fixed-1788832-1.patch2.41 KBmperrando
patch.patch3.13 KBmperrando

Comments

StatusFileSize
new2.41 KB

The proposed patch contains modifications to the info file. Sorry.

This is the same patch with only the correct files.

Status:Patch (to be ported)» Reviewed & tested by the community

Works for me and fixed a problem that was caused me all sorts of bother.

thanks for the patch, saved my day!

Status:Reviewed & tested by the community» Needs work

From reading the patch I believe this cannot correct. Drupal is already utf8. There cannot be a need to convert strings to utf8.

@hass locales_target.translation is of type BLOB, see more details in #1786876

I'm using this patch and it is working. It would be nice to see it committed, so there will be one less patch to worry about.

Converting an UTF8 string to UTF8 is waste of time from my point of view as it gives us nothing than extra DB load for nothing. I do not say this patch does not work, I'm only saying it's not proper coding.

(lt.translation using utf8)

Actually it is converting BLOB to utf8 string. This conversion makes comparison to be case insensitive and is the patch from #1786876 as said in the NOTE.

CLOB is for text. Maybe the field definition is wrong. Aside from this we normally use nvachar(max) in such cases as it's a lot more flexible. These SQL statements look also not DB independend. It may not work on pgsql, sqllite, mssql, oracle and others. Have you tested it on all of these db's?

I totally agree with you about that. Although there is no CLOB in mysql, TEXT can be used and I guess it will require some more changes. It would be nice to hear an opinion from this module maintainer.
This patch so far assumes your are using mysql(as most of us do), you ran into this problem and need a fix right now.