[TYPO3-core] RFC #12661: Problem with german "Umlaute" in BE file list, no thumbs generated

[Martin Kutschker]

Jigal van Hemert schrieb:
> Martin Kutschker wrote:
>> Jigal van Hemert schrieb:
>>> Solution: if $TYPO3_CONF_VARS['SYS']['UTF8filesystem'] is set
>>> LC_CTYPE locale is set with a generally available locale which
>>> supports the utf-8 character set. After escapeshellarg is called
>>> the original locale is restored.
>>
>> Ok, but why do you tyr to set 'en_US', 'American', 'ENG', 'English'?
> 
> It's hard to tell which locales are installed on a server. These are
> accepted by Windows servers.

My question lacked a proper wording. Why do you think that these locales use UTF-8 as encoding?

>> Nitpicking: Wouldn't it be better to set the locale also for the
>> whole BE? Currently the admin can only define the locale for FE
>> rendering but the BE runs always in the same locale (with the locale
>> set oustide of TYPO3).
> 
> Yes, that would be better. I think that the locale settings for the
> entire backend will influence more than just the working of
> escapeshellarg. What will happen with settings for date and time
> formats, etc.?

IMHO the right thing for most languages, ie proper formatted dates. But I recall that Dmitry said
that Debian locales for Baltic are broken.

> Anyway, this bug was introduced when esacpeshellarg was used instead of
> wrapping the filename in double quotes. This is the least disruptive way
> to solve it.

Could be, but I fear we still would need at least one configurable locale to make it work. I might
have installed de_DE.utf-8 but not en_US.utf-8.

Masi