Bug #14875
closed
if i use "config.locale_all = tr_TR", links in FE are broken
0%
Description
Maybe i Found a bug (i dont now if it is a Typo3, PHP or MySQL Bug?).
I have a site in german and turkish, it works without problems (Typo 3.8, server at mittwald Medien, Germany). I use UTF-8 in database and TS Setup. I can switch to turkish with config.language= tr in TS Setup.
If i set the language and country settings for turkish in TS Config Setup of root page with
"config.locale_all = tr_TR"
then i have names of days etc. in turkish too, but all of my links (internal or external)are in the FE broken! In BE anything looks ok...
I made a lot of tests with the same problem: Typo3 3.7, 3.8 and with PHP 4.3.0, PHP 4.3.3, MySQL 3.23, MySQL 4.1. Same Problem with Typo3 LiveCD.
Thanks a lot in advance!
Metin Yilmaz
I found only some discussion from 2003 like this:
http://lists.typo3.org/pipermail/typo3-debian/2003-August/000329.html
I found, that if i dont use RTE or htmlArea, and if i write "<link somedomain.tld>Test<link>" in a content element, that meens with small "i", then the links are working in the FE. So i think, maybe its a problem with the big "I". Because in turkish we have a "I with point" and a "i without point"...
(issue imported from #M1303)
Files
Updated by G Cenk almost 19 years ago
I do add my note here, although it does extend the view-ankle a bit. I did post my problems belonging to turkish language to news-lists, both german and english, but none could give me some advise, so:
Indeed, the "I" is causing troubles, since obviously typo3 seems to lowercase all markups in the forms internally for instance. I'm not into the code just atm. so please accept these "tutorial-meant" examples:
When there is a mark for a form-label like ###YOUR_CITY### in my template which might look like this in the output (en, de, tr): "Your city:", "Ihre Stadt", " ".
So I go back to the template and change the mark like this: ###YOUR_CiTY###. Result: "Your city:", "Ihre Stadt:", "Kentiniz:".
But in cases of marks containing more than one "I" this really starts getting "stupid", because it ends up in a quiz: I have to test if for example
###TRY_IT_AGAIN###, ###TRY_iT_AGAIN###, ###TRY_IT_AGAiN### or ###TRY_iT_AGAiN### makes my label appear.
Why should lower or upper make a difference? Turkish characterset is similiar to the american character set but has some additional charachters. In this case I just mention the '㟌', which is written as 'I' n uppercase, not being the same as 'i' or '㟌'. You see the disaster we face?
Updated by Stanislas Rolland over 18 years ago
I don't think that the broken markers are caused by core functions. Methods for manipulation marker arrays are provided by tslib_cObj, but they do not use strtolower or strtolower (except one, if specifically requested to do so).
Therefore, case shifting operations are performed by the plugins and need to be fixed in each extension.
Perhaps, coding guidelines should recommend the use of lower case iso-8859-1 markers. tslib_cObj::caseshift is a locale-safe method for case shifting iso-8859-1 markers.
Updated by Stanislas Rolland over 18 years ago
The attached patch fixes the problem with the RTE. This will work for entering new data or using the RTE to correct old data.
It will not fix the problem of correctly rendering old data with a tr_TR locale.
The patch was integrated in TYPO3 4.0RC3.
Updated by G Cenk over 18 years ago
Sorry for my misleading information about lowercasing all markups in the forms and thanks for solving this problem in sr_feuser_register which was in my case...
Updated by Martin Kutschker almost 17 years ago
This seems to be fixed in 4.0. Other occurrences of the basic problem may persist.
Updated by Chris topher over 10 years ago
- Target version deleted (
0) - TYPO3 Version changed from 3.8.0 to 3.8
- PHP Version deleted (
4) - Is Regression set to No