After last upgrade missing č ć š ž signs

Hi, after last Open Journal Systems upgrade from v.2.4.8.0 to v2.4.8.1 all signs ćčšž are transform to question mark.
What can be problem?

Hi @komir,

Can you check that the config.inc.php file has the same character set configuration – particularly the client_charset, connection_charset, and database_charset settings?

Regards,
Alec Smecher
Public Knowledge Project Team

Solved , add UTF8 , thank you

Hi, have a similar problem. After update from 2.4.4.1 to 3.1 don’t have ćžčđ but this time have UTF-8 inside config.inc.php
In config.inc.php have

Localization Settings ;
;;;;;;;;;;;;;;;;;;;;;;;;;

[i18n]

; Default locale
locale = en_US

; Client output/input character set
client_charset = utf-8

; Database connection character set
; Must be set to “Off” if not supported by the database server
; If enabled, must be the same character set as “client_charset”
; (although the actual name may differ slightly depending on the server)
connection_charset = utf8

; Database storage character set
; Must be set to “Off” if not supported by the database server
database_charset = utf8

; Enable character normalization to utf-8 (recommended)
; If disabled, strings will be passed through in their native encoding
; Note that client_charset and database collation must be set
; to “utf-8” for this to work, as characters are stored in utf-8
charset_normalization = Off

Hello anyone ? Can figured why dont have čćšž
Seems to me Default locale is OK

[i18n]

; Default locale
locale = en_US

; Client output/input character set
client_charset = utf-8

; Database connection character set
; Must be set to “Off” if not supported by the database server
; If enabled, must be the same character set as “client_charset”
; (although the actual name may differ slightly depending on the server)
connection_charset = Off

; Database storage character set
; Must be set to “Off” if not supported by the database server
database_charset = Off

; Enable character normalization to utf-8
; If disabled, strings will be passed through in their native encoding
; Note that client_charset and database collation must be set
; to “utf-8” for this to work, as characters are stored in utf-8
; (Note that this is generally no longer needed, as UTF8 adoption is good.)
; charset_normalization = Off