MySQL

Drupal 6.x. Table "node".

What should the value of the "language" field be if the displayed text is Chinese.

If a value is required, are there any other things that need to be done so that Chinese symbols are correctly displayed.

Any help appreciated.

Steve
http://prime357.org

ps. I've got a thread running at my site which I think this may be a part issue to it. As you can imagine it's becoming very confusing as all I see is either unicode or Chinese symbols (can't read Chinese).

Hope I'm not out of line with this request.

I'm now on the lookout for C++ contributors (and other like stuff in time). I started the site http://prime357.org, which is a separation from my personal blogging (http://superjacent.net - running) site, in early April this year. Too much geeky stuff was creeping into the running site.

I hope this is the right area for this question which refers to the 'thread' field of the table 'comments'. I provide a non php solution to convert Wordpress data to Drupal. I recently became aware that the thread field is not a string of decimal numbers but is in fact a string of base 36 (Vancode) numbers. I've created the necessary functions to convert to and from base 36 format but I'm a little confused re - the leading digit/character.

Here is an excerpt from http://api.drupal.org/api/function/int2vancode/5

<

blockquote>

We have a beta website that needs an integration to Ingram eBooks (yes, the same Ingram you know and love...this is their downloable eBook content division, an outfit called LSI = Lightning Source Inc.)

Ingram assigned someone on their side and we need to assign someone on our side to integrate their content into our website.

With the release of Drupal 6 support for PostgreSQL has come a long way in that core and contrib modules no longer have to know PostgreSQL syntax for CREATE TABLE and other table/index creation or alteration actions.

However when it comes to writing actual SQL in core and contrib modules there will be many situations where SQL that works fine in MySQL will not work in PostgreSQL. Most of the time this is due to the use of MySQL-specific SQL functions or to PostgreSQL's stricter adherence to SQL 92 or SQL 99 standards.

Now that D6 is out it's likely that many module authors will begin to port their modules to D6. With the schema API addition to D6, most authors will assume that PostgreSQL support is included without thinking about the SQL they write in their module functions. For those of us that are PostgreSQL supporters and have the knowledge to help module authors with their SQL this is a great time to make a push for more solid support of PostgreSQL in Drupal.

This Wiki can help to identify different types of SQL that will have problems in PostgreSQL and include solutions if any to these problems. Please add or update anything you think is helpful.

I'm assuming it's too late, but if not here's an easy performance win for D6:

http://drupal.org/node/215080

<

blockquote>The type column of the {system} table is currently a varchar(255) field. Yet in 99% of all Drupal installations it stores either the text 'module' or the text 'theme' and nothing else. This is already a strong case for making it an int column and defining constants for module and theme. Then, on every page, there is this query:
SELECT filename FROM system WHERE name = 'user' AND type = 'module';

I think it is safe to say that many developers already using or about to start using MySQL table type InnoDB. Some developers even changing default MySQL storage engine to InnoDB.
In many cases it make sense to convert table type if not for all tables, then at least for some tables.
In this situation will be nice if modules developers will state what table type is necessary for those modules and why.
Otherwise, its has to be investigated and tested for all modules in the project installation. May be it is fun but it is also a lot of time.
My suggestions for Drupal developers are

• include into modules .install file the indication of MySQL table type in the end of each table creation query like "CREATE TABLE `tablename` (...) ENGINE=InnoDB DEFAULT CHARSET=utf8" or "... ENGINE=MyISAM ...";
• include into 'INSTALL.TXT' file description of why these tables need to have those types.

That will give another developers enough information for making right decision on MySQL optimization of project's Drupal installations.