Actually unicode characters are converted by your browser into HTML code (such as &#268) where 268 decimal = 10C hex. elog just writes to file what it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is necessary since log files are ASCII and thus encode one charecter in one byte. Your Slovenian characters require two bytes in unicode, so some kind of "special" encoding is necessary.

Stefan

Hello Stefan,

thank you for the reply. The explanation does not solve my problem though. 

1) Could you elaborate, why the body text field CORRECTLY writes the character while the attribute fields write and display the HTML code?

2) If I understand you correctly the problem also contradicts your statement: "When an existing elog entry gets shown by the browser, the code is translated back to the character." and is visible in this very post. The subject field writes and displays it incorrectly, while the body text writes and displays it perfectly OK. See: Č č ?

3) We do not use any scripts. If we were to use a script to replace the HTML code with the actual character, the attribute fields would still display È instead of Č. Also, I have no idea how to write such a script. :)

Thanks,

Matej

In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put

allow html = 1

into your config file.

Stefan

This tag does not change the behaviour, but I have noticed that I only have the problem in Chrome and Firefox but not in Internet explorer.

Matej

So this is the result in the log file:

Opis: Test č Č
Attachment: 
Encoding: HTML
========================================
<p>Test &#269; &#268; body</p>

This is displayed as 

Opis: Test &#269; &#268;

Test č Č body

To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots below:

red square - the user name is changed immediately after saving. It is also written into the log file in the attribute "Lovec" preset as $long_name. This cannot be displayed correctly even when using HTML and the text tag.

orange sqare - This appears in translated menus and in the attribute "Pre�a" where the options are listed. The character is written correctly in the translation and the log file, but is displayed incorrectly as È and è.

pink square - After using the script on this attribute "Opis" to insert the html text tag the field correctly displays the characters. The minor problem remains when exporting this to a csv file where the html text tag remains.

I have no idea what effort it would take to change the ANSI background of the application to UNICODE and I can't really expect you to do this. On the other hand most modern applications go through this step eventually, mostly because of the Chinese and the Russian markets.

Thanks again for the otherwise great product, I guess we'll have to start using letters c and C instead. Best reagards,
Matej

I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.

Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current POC log resides.