Check the table’s character set by doing this: mysql> SHOW CREATE TABLE table_name If it’s not “utf8” then: mysql> ALTER DATABASE database_name CHARACTER SET utf8 Īlthough the database is now using UTF8 your tables and columns might be set to something else. This command will show you the “Db characterset”. MySQLįirst off, make sure the database is using UTF8. Follow my instructions at your own risk, and if you spot any errors, large or small, do post a comment or email me, as I’d love to know where I’ve gone wrong. Hopefully you can get your client to translate their Armenian here (very easy and get almost instant gratification in the cvs demo).I’m the first to admit my method has been haphazard here, stumbling from one error to another, Googling for a hasty solution to heave me over and on to the next one. I’m gonna send you an invite to the translation table on google docs.
My plan was gonna be to create the database from the current xml schema file, and then dump it into a text sql file, then make the needed changes, and then should be able to substitute this file for the current xml schema file. The problem is the dumpfile is in an xml schema which doesn’t allow inserting limits to the key sizes. Bascially there are about 4 lines that create keys that are too large (UTF takes up more bytes), which can easily be corrected if the dumpfile were of the normal text variety (google utf8 and phpgacl and you will see several projects that have explained the simple changes that need to be made). Firefox goes to UTF-8 automatically in OpenEMR (this is what is happening in the CVS demo), however all the other browsers (IE, google chrom, opera, safari) don’t go into UTF8 by default and special charcaters get jargoned up. These seem to be intermittently interspersed throughout. Regarding the pages UTF8 header meta-tags. The real key is removing any lingering latin1 encoding in the new installs or the users database will degrade. Then you avoid confusion during installation (most people are clueless to this stuff it took me several weeks to develop any appreciation for this stuff). Then the unusual user who wants something else can always directly change it through mysql (i think this is possible). Could always make that the default for the database on install.
PHP MYSQL CREATE DATABASE UTF8 PLUS
Plus unicode seems like it pretty much works for everything.
PHP MYSQL CREATE DATABASE UTF8 INSTALL
Even though your gonna force the database to UTF-8, you may still want to consider adding this to end of each table (Then your in effect forcing every install to UTF-8 even if make database shell first I think this will be important since your gonna now be forcing read/writing of UTF8 to the mysql database in the new installs): Agree with getting rid of the bin part(they are using this for numbers, since collation is much simpler), then can get rid of all of that set utf8 collate crap. The current utf8-bin/utf8-unicode separation is sort of clever but is a huge pain to maintain. Figured it would take me like a year to begin to implement this with my limited time. Once the entire database is forced to UTF-8 encoding we are then one step closer to having functional chinese/russian (there is a demand for this) Wouldstill need read/write utf-8 mysql command in library/translator.inc, ensure proper meta header tags on all the pages, and make the phpgacl utf-8 complaint, which will involve making another dumpfile and shortening some key). I suppose could leave the collater up to the database but UTF8-unicode seems to be a good broad shotgun approach collator (again the concept of encoding/collation is not within the grasp of most users until its too late). If possible, agree would be cleaner to set the default UTF-8 encoding during the database creation (but is this possible, and what happens to users who create the shell database themselves?) instead of placing into database.sql. Right now the majority of database is forced to utf-8 encoding with collation of characters strings by utf-8-unicode (values get default collation of utf-8-bin), along with an annoying amount of latin1 mixed in.įorcing complete UTF-8 encoding in database is a good idea since most users have no clue what this is until it’s too late(is a real pain if a user realizes they need to migrate from latin1 to utf-8 lots of horror stories online).
This will have direct effects on the translation project. Bradymiller wrote on Friday, May 01, 2009:
0 kommentar(er)
