[MAGNOLIA-139] Kupu messes up with umlauts (and other special chars) Created: 26/Oct/04  Updated: 08/Nov/04  Resolved: 27/Oct/04

Status: Closed
Project: Magnolia
Component/s: templating
Affects Version/s: 2.0 Final
Fix Version/s: 2.0 Final

Type: Bug Priority: Major
Reporter: Markus Tobler Assignee: Vinzenz Wyser
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

tested on WinXPPro


Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When entering umlauts or other special chars in the kupu rich text editor they are rendered (or probably stored) corruptly.
I assume that the error occurs when the data is stored, because if I open the dialog of a text which comes with the beta2 release and save it, the error occurs. (Before those special chars, which are now corrupt, have been rendered correctly).



 Comments   
Comment by Markus Strickler [ 27/Oct/04 ]

Hm, adding
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
to templates\jsp\samples\global\head.jsp seems to make the encoding consistent in Firefox.
IE still messes up the encoding in kupu. However if I see this correctly the editor IFrame doesn't set a charset.
So maybe adding a charset to the Editor IFrame in info.magnolia.cms.gui.dialog.DialogRichedit.drawHtmlEditor() will help.

Generated at Mon Feb 12 03:14:29 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.