[Typo3-dev] tslib_fe->csConv()

[Martin T. Kutschker]

Kasper Skårhøj wrote:
> 
>>I was thinking about two other possible conversions: from DB charset and 
>>from locale charset.
>>
>>So instead of the mentioned method perhaps we could have these ones:
> 
> We cannot have things *instead*. We can have things in *addition*. Guess
> why.

I have a bad habit of renaming thing when I get the impression that I 
have an idea for a naming scheme that is so much nicer :-)

>>dbConv would get it's "internal" conversoin arguments by 
>>SYS[forced_charset] and config.metaCharset. Can be used on results of 
>>SQL queries.
> 
> Where would this function be called? If people know the charset of the
> input string they just use "csConv" with the second argument set.

It would relieve them from the burden of knowing the internal charset. 
Mind that you have to check if SYS[forced_charset] is set, and if not, 
consult the "magic" array of t3lib_cs.

> BTW, there is a property for stdWrap called "csConv" which allows just
> that.

Good for Typoscript, but in a plugin I want a PHP API.

> Considering logic regarding forceCharset might make some sense but it's
> not vital

It's a convenience function.

> Say that all information in the system is in iso-8859-1 and you want
> utf-8 pages for some reason. Then something like "page.stdWrap.csConf =
> iso-8859-1" will do the trick if "config.metaCharset = utf-8"

Typoscript != PHP

>>localeConv could make some eductated guess on the charset of the locale, 
>>but should make use of an override via something like 
>>config.localeCharset. Can be used on results of locale dependent system 
>>libraries (like strftime()).
> 
> I'm not into that.
> 
> Could we start by making the intelligent function for finding the
> charset of the locale and then just use csConv?

Sure.

> I suggest we implement this for the places where TypoScript offers to
> extract locale dependant information (like stdWrap.strftime)

That was my plan, but then I relaized that an extension author could 
need the function for a strftime call in a plugin.

>>The initialization of the interbal charset vars could be moved into the 
>>"constructor" (instead of initLLvars).
> 
> Lets keep it in csConv. There it is initialized if used and creates no
> significant overhead.

The reason for suggesting to move the initializatoin is that 
initLLvars() will be called when you use the label API, but some code 
might want use siteCharset, etc but not the label calls.

It's not clear that you have to call initLLvars to get correct charset 
infos.

>>Guessing of the locale charset could be done via a platform dependent 
>>(Unix uses mostl iso, Windows MS uses specifc charsets, OS X uses ???) 
>>mapping table.
>>
>>Something like this:
>>
>>Take the language part out of the locale (de_DE => de, pl-PL => pl, 
>>italian => it).
>>Make a lookup in the table of the platform (de: Unix => iso-8859-1, MS 
>>=> windows-1252)
> 
> Whatever.
> 
> As long as there is some hardcoded way to set it when the intelligence
> breaks.

I'm not really happy with this. But I fear many users would stumble 
across the locale problem.

Masi