[ic] Use one table for product descriptions in different languages

[Ethan Rowe]

Daniel Davenport wrote:

>  
>
>>>>lars.tode at bpanet.de 07/08/05 12:34 PM >>>
>>>>        
>>>>
>>Hallo list.
>>
>>One of our customers thought about translate his shop in different
>>languages. The biggest part of the translation is done by the locale.txt
>>There is just one exception, the title and description of each product.
>>
>>One possible solution is to use different ProductFile for each language,
>>using the ProductFiles directive in the locale.txt
>>In this solution, I'd to create more than one product table and to
>>update both tables if something changed (data, table structure etc).
>>This idea is not bad, but i search for something different.
>>
>>Another solution I found today on www.icdevgroup.org, DescriptionField.
>>I think the solution ist not so bad, except if you add more languages.
>>
>>My idea is just add one more table where every descption for every
>>language and item is stored in.
>>
>>I thought about following table layout :
>>
>>item_code
>>ianguage_id
>>title
>>description
>>
>>Is there a possibillity the modify/configure Interchange in that way,
>>that it can handle this kind of table?
>>Or is the only way to create an own usertag, which reads the data from
>>the second table?
>>
>>Thanx in advanced,
>>
>>Lars
>>    
>>
>
>You'd have a hard time telling IC to look at both the sku and the language with a scheme like that.
>
>[data table=descriptions field=description key=1
>    foreign.item_code=[scratch sku]
>    foreign.language_id=[scratch current_language]
>]
>
>looks like it might grab the data you need, assuming you've [tmp]ed or [set] your sku and language.
>If you want it simpler than that in a page, you'll probably need to write a tag....but the tag could just be a wrapper around the data tag above.
>  
>
I forgot to mention:
Encoding is not fun.

If you need really flexible multi-lingual support (as in, stuff outside 
Interchange's most familiar world of latin-1), you'll probably want to 
store your descriptions as unicode (in which case UTF-8 is your choice, 
if on MySQL or PostgreSQL).  This means you have to deal with the proper 
encoding settings for any pages affected by this.  Moving from a 
single-byte encoding to a multi-byte encoding is not particularly 
pleasant.  You need to know exactly how the data pulled from the 
database is encoded before you just plop that data willy-nilly into your 
page output.  If you have a bunch of latin1 data in the output, and then 
you try to put some UTF-8 into it, you're gonna get a bunch of junk 
characters.  In my case, I stored everything as UTF-8 in PostgreSQL, use 
an AutoLoad to set the proper Content-Type header to put all page 
encodings as UTF-8, and then made certain that any data from the 
database would be encoded properly.  For PostgreSQL, all data pulled 
from the database comes as UTF-8 octets, as in each character in a 
string corresponds to a byte (which since Perl 5.6 you cannot 
necessarily count on ordinarily).  In other words, the data returned to 
Perl was essentially the raw UTF-8 data; this is a perfectly fine form 
to place directly into the page (via stuff like [sql-param description], 
etc.).  But it means that I cannot easily use regular expressions 
against that data, because each character in the data represents a byte 
rather than an actual character.

The point being, if you haven't looked into the encoding side of 
multiple languages, and are going to need to go outside something like 
latin1, you will need to spend a bunch of time sorting out how you'll 
deal with the encoding.  Nothing specific to Interchange, there, of 
course.  If you're sticking to a relatively limited set of languages, 
confined entirely to Western Europe or something, you may be safe from 
this delightful considerations.

Good luck!
- Ethan

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com