[ic] Use one table for product descriptions in different languages
ethan at endpoint.com
Mon Jul 11 13:31:15 EDT 2005
Daniel Davenport wrote:
>>>>lars.tode at bpanet.de 07/08/05 12:34 PM >>>
>>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 :
>>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,
>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.
End Point Corporation
ethan at endpoint.com
More information about the interchange-users