Bug #14984

Editpanel confirm dialogs (del/hide) don't display umlauts/etc

Added by Ernesto Baschny over 14 years ago. Updated almost 14 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


The edit panel has a hide and delete buttons that open a javascript confirmation dialog. This works nice in englisch, but if the user has set the BE-language to a language that uses non-ascii chars in these strings (e.g. german), the confirmation dialogs appear with these characters displayed as URL-encoded UTF-8 entities.

The problem is that javascript dialogs doesn't support URL-encoded strings and not even UTF-8 entities.

The attached patch solves the problem, and allows us to display the confirmation prompts with umlauts etc. The solution is:

1) t3lib_tsfebeuserauth::extGetLL has a new parameter, allowing us to return the string in the default charset that the BE-user is using (instead of UTF-8 entities)
2) In tslib_content::editPanel we now get the strings for "hideConfirm" and "deleteConfirm" using this new parameter
3) In tslib_content::editPanelLinkWrap the $confirm parameter goes through $GLOBALS['LANG']->JScharCode() to get properly encoded and displayed in the dialog.

The attached patch was created for current CVS-head, but also applies to TYPO3 3.8.0 nicely.
(issue imported from #M1472)

editpanels-javascript-dialog-charset-fix.diff View (4.32 KB) Administrator Admin, 2005-09-21 12:57

editpanels-javascript-dialog-charset-fix.patch View (4.08 KB) Administrator Admin, 2005-10-21 09:52

utf8_JS_2005-10-26.patch View (5.83 KB) Administrator Admin, 2005-10-26 17:56

Related issues

Related to TYPO3 Core - Bug #14264: getUpdateJS: broken when using UTF-8 and IE Closed 2004-08-05


#1 Updated by Ernesto Baschny over 14 years ago

After a discussion in typo3-dev, Bernhard Kraft convinced me that the JScharCode isn't needed anymore (in step 3). The proper way of outputting UTF8 strings in JavaScript alert()s is to: quote single quotes with an "\" and have the string go to htmlspecialchars.

The updated patch changes this.

#2 Updated by Bernhard Kraft over 14 years ago

I made an example:

And will mark this bug as duplicate of:

#3 Updated by Bernhard Kraft over 14 years ago

The actual patch:
fixes following problems:

Mailform goodMess, badMess, emailMess with utf-8 entities. (No bug #)
FE-User admin/Direct Mail subscription utf-8 entities in values (Bug #14264)
JSMENU with utf8 (Bug #14264)
Editpanel confirm dialogs with utf8 (Bug #14264)

please try it out and write me back if you had a negative or positive experience:

If this works fine and no problems come up it will get added to the core and be contained in T3 4.0.0

#4 Updated by Ernesto Baschny over 14 years ago

I've just tested the patches on a plain 3.8.0 setup (should work the same in 3.8.1) and it worked. In "native" iso-latin-1 mode and also with forceCharSet set to utf-8. At least the dialogs from the editpanels work nicely with the last patch from Bernhard.

#5 Updated by Ernesto Baschny over 14 years ago

I can also confirm that the FORM-validation alerts also work properly with the latest patch.

Also available in: Atom PDF