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

Chaged to
[i18n]

; Default locale
locale = en_US

; Client output/input character set
client_charset = latin1

; 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 = latin1

and now seems ok

Hi @komir,

That’ll be OK to use for now, but at some point I’d definitely recommend transcoding your database so that everything is in UTF-8. That’s done outside of OJS using tools like mysqldump and iconv; you should be able to find guidance on StackOverflow.com.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi, yes, you are right. I do a little research and see all my tables are
utf8_general_ci is that OK?
In fields, I don’t see šžćč but some sights, like, in table “users” “the first name” I have “Željko”, not Željko
Do I need all of that to manually convert to “Željko”, I mind need to manually convert all Ž to ž ?

Hi @komir,

I would really recommend against doing any kind of conversion manually (e.g. by replacing characters one at a time) – you’re guaranteed to miss some of them and will end up with a mix of encodings, which is much harder to fix. I’d suggest using mysqldump and iconv to perform the conversion – something like what’s documented here, though I haven’t tried these specific directions: Converting MySQL from LATIN1 to UTF8 - bdunagan

Make sure you have a good backup, and test well before moving ahead with anything – it’s a pain to unscramble character sets once they start to get mixed, e.g. if you make a change, users add new data, and then you discover that the new data and the old data disagree on encodings.

Regards,
Alec Smecher
Public Knowledge Project Team