CoreCommunity ExtensionsIncubatorDistributionsTYPO3 4.5 ProjectsTYPO3 4.6 ProjectsTYPO3 4.7 ProjectsTYPO3 6.0 ProjectsTYPO3 6.1 ProjectsTYPO3 6.2 Projects (+)

Bug #13550

AZ Tabs do not work for Turkish Characters

Added by Peter Murray about 2 years ago. Updated 3 months ago.

Status:Accepted Start date:2011-03-02
Priority:Should have Due date:
Assignee:Dirk Wildt % Done:

0%
Category:Localisation Spent time: -
Target version:4.7.0
Votes: 0

Description

When the following Typoscript is used, WXYZ tab works as expected but tabs for CÇ Iİ OÖ SŞ and UÜ do not:

plugin.tx_browser_pi1 {
a-z_Browser {
tabs {
0 = All
0.special = all
1 = 0-9
1.valuesCSV = 0,1,2,3,4,5,6,7,8,9
4 = CÇ
4.valuesCSV = C, Ç
10 = Iİ
10.valuesCSV = I, İ
16 = OÖ
16.valuesCSV = O, Ö
19 = SŞ
19.valuesCSV = S, Ş
21 = UÜ
21.valuesCSV = U, Ü
23 = WXYZ
23.valuesCSV = W, X, Y, Z
24 >
}
charset = utf-8
}
}

The tabs all report the correct number of items on mouseover.

TYPO3 4.5.2
Browser 3.6.1

History

#1
Updated by Peter Murray about 2 years ago

I have further tested the AZ tabs, with individual letters on the tabs.

The links generated by the extension are not all correct.

For example the extension generates the URL with &tx_browser_pi1[azTab]=ae instead of &tx_browser_pi1[azTab]=İ (capital dotted i, which displays the correct list).

Also, the case conversion is not correct.
The URL generated for the I (uppercase dotless i) has &tx_browser_pi1[azTab]=i (lowercase dotted i) and gives the correct results but I would expected the URL to have &tx_browser_pi1[azTab]=ı (dotless i) instead.

#2
Updated by Dirk Wildt about 2 years ago

  • Category set to Localisation
  • Assignee set to Dirk Wildt
  • Target version set to 4.7.0

#3
Updated by Dirk Wildt about 2 years ago

  • Status changed from New to Accepted

#4
Updated by Peter Murray about 2 years ago

When will version 4.1.0 be released? Can this issue be fixed earlier than version 4.1.0? We have a client who needs to work as soon as possible.

#5
Updated by Martin Muskulus 3 months ago

I have a similar issue that might be related on a german website with TYPO3 v4.7.8, browser v4.4.3, database using utf8_general_ci and frontend output using utf-8 charsets.

I click on the letter U in indexBrowser and the list does NOT show fe_users with last_name beginning with Ü. The link to the U-list in indexBrowser has the correct number of fe_users in title but the shown list is shorter.

As a workaround the list works fine if I change zz_getSqlLengthAsRow() in pi1/class.tx_browser_pi1_navi_indexBrowser.php
from 

$arrStatement[] = "LENGTH( '" . $specialChar . "' ) AS '" . $specialChar . "'";
to 
$arrStatement[] = "CHAR_LENGTH( '" . $specialChar . "' ) AS '" . $specialChar . "'";

I do not understand why the WHERE-statement to filter datarows by column uses the length of string in bytes (LENGTH()) instead of characters (CHAR_LENGTH()).

MySQL's function [http://dev.mysql.com/doc/refman/5.1/en/string-functions.html#function_left LEFT] is multibyte safe, so i see no need to manipulate any length at all.

I tried the following query to verify and got a result of 1 for all users starting with U and Ü.

SELECT find_in_set('U', LEFT(last_name, 1)) FROM `fe_users` WHERE last_name like 'U%'

I assume the correct solution would be to check every SQL-function if it is multibyte safe and let them ignore the length parameter (or use length = 1 as for any other character).

Also available in: Atom PDF