0.9.6.2-rc2. problem with russian encoding after install

• 1. encoding windows-cp1251 for language russian
• 2. encoding utf8 for language russian_UTF8(stupid title ).

• 1. rename installer language to russian_UTF8(folder ’russian’ rename to ’russian_utf8’, and after install we have encoding utf8 and language russian_UTF8, which is right. This is the most easiest way.
• 2. write encoding cp1251 to database(modx_charset in table system_settings) by default at install proccess. This is bad solution
• 3. This way may breaks backward compatibility and breaks 0.9.6 stable branch.
  Using encoding cp1251 is a nightmare. So i think we need to move to the utf8 as default encoding.
  So rename /manager/includes/lang/russian.inc.php to /manager/includes/lang/russian_cp1251.inc.php,
  rename /manager/includes/lang/russian_UTF8.inc.php to /manager/includes/lang/russian.inc.php
  2 above steps should be do with all 3-party plugins, snippets, etc ( I know this is not easy ).

IMHO, everyone should be using UTF-8.

svn mv install/lang/russian install/lang/russian-UTF8
svn mv install/lang/russian-UTF8/russian.inc.php install/lang/russian-UTF8/russian-UTF8.inc.php
svn mv manager/includes/lang/country/russian_country-UTF8.inc.php manager/includes/lang/country/russian-UTF8_country.inc.php

IMHO, everyone should be using UTF-8.

Quote from: OpenGeek at Aug 08, 2008, 02:14 PM

IMHO, everyone should be using UTF-8.

Yes, I agree too.

I’d note that almost all Russian MODx developers have many encoding issues with the latest version of MODx even if they try to use UTF-8 encoding.

These issues was in the earlier versions too and we had fixed it with hacking MODx core code.

But we’d want to ask the developers to fix these issues now.

It’s really one of the big problem of MODx in Russian Community because sometimes this issue forces the new developers to be disappointed with MODx and to choose another CMS’s.

That’s simply not true Fuzzy, the latest version includes these hacks; this is a matter of understanding the problem.  However, the set of patches to allow you to run with utf8 translation from non-utf8 data sources via SET NAMES is a hack and IMO, is not the right way to address encoding problems in the first place.  Yes it works, but that doesn’t make it the right solution.

Folks need to realize that unless they create the MODx database in MySQL explicitly with a utf8 collation (or let the MODx installer create it automatically after selecting a utf8 collation), it’s going to be using the default collation for the database, and thus, MODx is going to store data in whatever the default collation is (typically latin1_swedish_ci).  All using SET NAMES (instead of SET CHARACTER SET) does is get the MySQL client API to translate the latin1 to utf8 on the fly.  This is not lossless.

the problem started in this thread is not related to mysql database.
simple solution is described here http://modxcms.com/forums/index.php/topic,27946.msg170031.html#msg170031
the main problem that after install we have encoding ($modx->config[’modx_charset’])
setted to ’utf8’ and language($modx->config[’manager_language’]) setted to ’russian’. But the russian translations file named ’russian.inc.php’ is encoded with cp1251. And than we open manager window, we see squares instead of the real text. so the simple solution is to rename language install dir, similar to francais, jananese languages.
But uses uppercase UTF8 in the middle of the file name.
P.S. sorry for my english

Right, in order to run a UTF-8 site, you must use UTF-8 encoded language files for the backend. And make sure you mean UTF-8 (utf8 is only valid for mysql) as the modx_charset. IMO, all the main language files should be UTF-8, will others created only for the purpose of running sites that require special encodings for some reason.