Hello Jason:

Thanks for your input.

I did think of this possibility; those hash tables MySQL has
available are certainly going to speed things up (if you
have the memory).

My mutlilanguage system could encorporate your idea; I will
give you a run down of how it works.

First you keep separate files with what are to be hash
entries of all _lines_ in the page, lets call this file
en-ints (it could be sp-ints for spanish).  The keys access
data which is language specific. This is because there is
lots of other text not in the database which appears in the
web page.

Suppose you have a header on the page <H2>Hello World</H2>

en-ints could have an entry like "header = 'Hello World'"
sp-ints could have a similar entry "header = 'Olla Mondo'"
(my spanish is terrible)

You might write a script like (CGI.pm)
$obj->h2($language['header']);
This assumes %language is the hash loaded with data from
en-ints.

I am choosing this system because word for word translations
result in grammatical errors I do not want.

If you had one table with all attributes in all supported
languages (we would have a slight mess with (select * from
table_name) we could name the attributes according to the
language they represent.  The right attributes get accessed
when the CGI scrip loads ..-ints containing the language to
use because the key entries of ..-ints reflect the attribute
name change:)

You also might have to share attributes within the database
(like picture).  Having multiple tables creates a redundancy
of this data...  

My only concern in having tuples so long that I get other
unforseen side effects.  Also a limit in tuple size might
limit my ability to include additional languages.

Regards,

Leo Cambilargiu

Jason Landry wrote:
> 
> Leo,
> 
> There's another alternative that I found intriguing with MySQL that I
> haven't tried - but it might be a really good solution for you.  Mind you I
> haven't tried this, but I found the idea somewhat fascinating.
> 
> Have you looked into the temporary table functionality of MySQL?
> 
> Suppose you have n tables with languages like this:
> 
> language_english
> language_french
> language_spanish
> language_german
> 
> Now when you establish your connection to the database, do this:
> 
> create temporary table language select * from lang_english // pick your
> lanuage in code
> 
> Now the rest of you code can refer to "language" as a table -- and you can
> add as many languages as are needed modifying only the stub of code that
> initially selects the language.
> 
> ----- Original Message -----
> From: "Leo Cambilargiu" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, March 18, 2001 8:30 AM
> Subject: Tuple length Question
> 
> > Hello All:
> >
> > I am looking into mysql as a web solution.  I am
> > implementing a multilanguage scheme.
> >
> > I am considering separating the different languages by the
> > following three methods.
> >
> > 1.  Use different tables to hold different languages.
> >
> > 2.  Use the same table with another key (lang).
> >
> > 3.  Add extra attributes to a table and pick the ones
> > containing the language I want.
> >
> > I am exploring possibility number 3 at the moment.
> >
> > My question is, how long can a Mysql myisam table tuple be?
> >
> > Currently I like the idea of increasing the number of
> > attributes except for this  possible constraint.  I might
> > have 6 to 10 languages supported max.  I'll start with 2.  I
> > will have no more than 15 attributes total and possibly 5
> > will be shared between languages.  This means i'll have to
> > add another 10 attributes per language implemented.
> >
> > Thanks in advance.  Please email me at [EMAIL PROTECTED] or
> > [EMAIL PROTECTED]
> >
> > Leo Cambilargiu
> >
> >
> > ---------------------------------------------------------------------
> > Before posting, please check:
> >    http://www.mysql.com/manual.php   (the manual)
> >    http://lists.mysql.com/           (the list archive)
> >
> > To request this thread, e-mail <[EMAIL PROTECTED]>
> > To unsubscribe, e-mail
> <[EMAIL PROTECTED]>
> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
> >

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to