AZ Tabs do not work for Turkish Characters
When the following Typoscript is used, WXYZ tab works as expected but tabs for CÇ Iİ OÖ SŞ and UÜ do not:
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
charset = utf-8
The tabs all report the correct number of items on mouseover.
Updated by Peter Murray over 10 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.
Updated by Martin Muskulus over 8 years 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
$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 (
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).