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

Comments

mperrando’s picture

StatusFileSize
new2.41 KB

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

This is the same patch with only the correct files.

apemantus’s picture

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.

tYb’s picture

thanks for the patch, saved my day!

hass’s picture

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.

dscutaru’s picture

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

hass’s picture

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)

dscutaru’s picture

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.

hass’s picture

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?

dscutaru’s picture

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.

pmusaraj’s picture

Issue summary:View changes
StatusFileSize
new2.53 KB

I rerolled the patch from #1 to have it work with current -dev release. Thanks!