Bug #14984
closed
Editpanel confirm dialogs (del/hide) don't display umlauts/etc
0%
Description
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)
Files
Updated by Ernesto Baschny over 18 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.
Updated by Bernhard Kraft over 18 years ago
I made an example:
http://think-open.org/kraftb/confirm.php
And will mark this bug as duplicate of:
http://bugs.typo3.org/view.php?id=277
Updated by Bernhard Kraft over 18 years ago
The actual patch:
utf8_JS_2005-10-22.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:
kraftb@kraftb.at
If this works fine and no problems come up it will get added to the core and be contained in T3 4.0.0
Updated by Ernesto Baschny over 18 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.
Updated by Ernesto Baschny over 18 years ago
I can also confirm that the FORM-validation alerts also work properly with the latest patch.