> Hmm, in your situation, you might need to select and output dinner menus
> from the same table in a mixture of languages, right?....a fairly
> complicated problem. Not to mention your overseas sites, of course.

Hmmm. How did you guess that? ;)

> The case of "multi-lingual menus" is fairly simply solved, by having 1:1
> relations from your main-language "menu" table to one table for each
> individual character set that doesn't work with the main charset of the
> database...or a 1:many to a single table containing a column for each
> charset. The problem with the latter is that you have to change metadata
> to add a new language, whereas with the former you deploy an optional extra
> table. Your application code can take care of "stubbing" tables that may
> be absent, so an extra language needn't break your code, as the "change
> metadata" approach would.

Sounds great. I'm not so much worried about translating the actual
menus of products because most customers input their menu onsite or we
do it for them for a fee.

I was mostly concerned with ordering of records when localized character
sets are used. For instance, in the following report:

http://www.datatrakpos.com/WebInfo/SalesByCategory.pdf

Unlike many of the reports where we try to base grouping and ordering on
integer keys, reports like this one are grouped and ordered by the
actual names of the products and "Categories" they belong to.....


BTW Helen, do you have an email notification for when your books is
ready? I'd be very much interested in reading it.

Lee