Re: I18n issues with 4.1.1 and 5.0

Alexander Kirillov writes:
> Hi guys and Happy Easter to all of you,
> I've tried to upgrade to either 4.1.1 or 5.0 recently and spent a week
> trying to make my apps work with 4.1.1 or 5.0 and than downgrading back 
> to 4.0.18.
> That's a pity it nearly worked and seems so easy to fix and still 
> rendered  my apps practically unusable.
> Now back to details. I have a bunch of database, table and column names 
> in cyrillic (koi8r).
> Generally it's a bad practice to use non-ascii names but offers an easy 
> localization of
> some db-driven apps. The main problem is there's no specific encoding 
> assosiated
> with user, database, table and column values in system tables. They are 
> now all utf8 internally
> but still mysql_install_db declares all these fields BINARY. If client 
> encoding is anything else but utf8
> you won't get readable results doing SELECTs on system tables.
> What is more the behaviour of various administrative commands which 
> retrieve or set user, db ot table values
> in system tables like GRANT/SHOW GRANTS, SHOW CREATE TABLE, SHOW BINLOG 
> EVENTS and so on is inconsistent.
> For example you use GRANT smth on a table with cyrillic name and it 
> works and you can SELECT values
> from mysql.db and get meaningful results IF(!) your client encoding is 
> set to UTF8.
> But SHOW GRANTS yields unreadable results no matter what your client 
> encoding is.
> All cyrillic names in SHOW GRANTS output are screwed up. I've tried 
> different combinations
> of client encodings and encodings explicitly set for user/db/table 
> fields in system tables. No luck.
> Same stands for master binary logs where a slave chokes with every query 
> with non-ascii db/table name.
> Viewing the logs (SHOW BINLOG EVENTS) one may notice the queries are OK 
> and show up properly converted to encoding specified by the client. But 
> all USE `db` statements inserted by the master are in God knows what 
> encoding
> and show up as meaningless rubbish.
> I would suggest to explicitly declare user, db, table and column fields 
> in system tables to be utf8  and
> use normal character set conversion rules when fetching data for the 
> client (it seems to be working well for userland tables).
> A slave can always request the data to be in utf8 format and this seems 
> to be compatible
> with new MySQL layout where each column may use different encoding.
> If the requested data can't be converted to the encoding specified by 
> the client MySQL could either fetch a binary value
> or produce a fatal runtime error which is probably a better choice.
> Thanks for your help and looking forward for fully working i18n support 
> in MySQL.
> Cheers,
> Sasha

Hi!

Thank you for writting to us.

For the time being, the privilege and errors / warnings system will
work only as described above.

We have on our todo full localization of the both, but it will take
some time to be implemented.

-- 

Sincerely,

-- 
For technical support contracts, go to https://order.mysql.com/?ref=msmi
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Mr. Sinisa Milivojevic <[email protected]>
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB
/_/  /_/\_, /___/\___\_\___/   Full time Developer and Support Coordinator
       <___/   www.mysql.com   Larnaca, Cyprus



-- 
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe:    http://lists.mysql.com/[email protected]