The database charset should always match the first part of the database collation (up to the first underscore); collation is just a subset of charset. But connection charset is all we are concerned with.
Forgive me to ask such a stupid question, but I think the installer should be very precise : currently, it says "Connection character set:" but in phpMyAdmin there are two things "MySQL charset" and "MySQL connection collation" and they can be different (in my case, MySQL charset is utf8 and default collation is utf8_unicode_ci but all my MODx installs use latin_swedish_ci as collation=> I am a bit lost as to why it is so...).
Easy to get confused since the label we apply is a combination of both ("connection" + "charset").
If I understand correctly MODx looks up the DB collation to determine which charset is used... in my case it won’t work since one is utf8 and the DB’s collation is (somehow) different from the default collation for my server...
Do I make sense ?

This needs a JIRA ticket first of all. Then you attach a patch (a unified diff created by running svn diff on your local working copy containing your changes). You can also create a code review and attach the patch so the team can review the code using Crucible; this way we can review the changes in the context of the code online as a team before we commit anything. I’d love to see that happen here as a test of this.
I got the source code from SVN, but once my tests will be finished, how could i deliver the new version of these files ? and how can I get the translation for the other languages (for French and Spanish it’s ok) ?
Then we can present a proper dropdown of valid values on the next page (or maybe as a dynamically activated control on the main page). Otherwise, an invalid collation (one not available on the server configuration) will cause the server to error when we issue the SET CHARSET command.
maybe as a dynamically activated control on the main page ?I will be interested to find and implement a solution
Agreed...
If I take the option to display a dropdown list for the available collations, this new page will have only this drop down. A new page for only one dropdow seems rich ?
I meant once the database settings are entered, activating a type-ahead control that populates the drop down from collations returned by an Ajax request. The challenge is safely getting the db settings to the Ajax request I would guess.
What do you mean bymaybe as a dynamically activated control on the main page ?I will be interested to find and implement a solution
// get collation / charset
$getCharCol = mysql_query("SHOW CHARACTER SET");
if (mysql_num_rows($getCharCol) > 0) {
//$charSelect .= "Available Charset/Collation settings<br />";
$charSelect = "<select id=\"database_collation\" name=\"database_collation\">";
while ($row = mysql_fetch_row($getCharCol)) {
$charSelect .= "<option value=\"".$row[2]."\">".$row[2]."</option>";
}
$charSelect .= "</select>";
}big5 | big5_chinese_ci
dec8 | dec8_swedish_ci
cp850 | cp850_general_ci
hp8 | hp8_english_ci
koi8r | koi8r_general_ci
latin1 | latin1_swedish_ci
latin2 | latin2_general_ci
swe7 | swe7_swedish_ci
ascii | ascii_general_ci
ujis | ujis_japanese_ci
sjis | sjis_japanese_ci
hebrew | hebrew_general_ci
tis620 | tis620_thai_ci
euckr | euckr_korean_ci
koi8u | koi8u_general_ci
gb2312 | gb2312_chinese_ci
greek | greek_general_ci
cp1250 | cp1250_general_ci
gbk | gbk_chinese_ci
latin5 | latin5_turkish_ci
armscii8 | armscii8_general_ci
utf8 | utf8_general_ci
ucs2 | ucs2_general_ci
cp866 | cp866_general_ci
keybcs2 | keybcs2_general_ci
macce | macce_general_ci
macroman | macroman_general_ci
cp852 | cp852_general_ci
latin7 | latin7_general_ci
cp1251 | cp1251_general_ci
cp1256 | cp1256_general_ci
cp1257 | cp1257_general_ci
binary | binary
geostd8 | geostd8_general_ci
cp932 | cp932_japanese_ci
eucjpms | eucjpms_japanese_ci
I will try to work on that tomorrow.
Not sure, I think all it needs to do is connect to the db server and not a specific database, therefore if you can connect then you can get the results...not 100% sure though, will do some testing. I think corioco is moving ahead with this and may be much better qualified to fine tune it
Does this work, even if the database does not yet exist, and thus the connection test fails?
If the database does not exist, we create the database during install, so make sure this works when you don’t have a valid database connection, or we’ll have to change the test db connection to be a test db connection and/or create db. But of course, you can’t create the db until you know what collation/charset they have selected. Grrrrr....
The user test his database connection, a message "Connection to host: passed... Checking database: passed" is displayed (or not). If the DB connection is OK a list of available collation is displayed. The user choose the collation and then continue to the admin user part.