Daniel Davenport wrote:
suppressed 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, LarsYou'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 suppressed _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.