Paul Hastings' comments are excellent. With Tapestry we'd already developed a system where all the content was stored in a single table in the database, so it's been somewhat easier although still challenging to add a languages table which holds the names of various languages along with a unique identifier and some other information. With the existing table we separated all but a handful of fields which would be the same across different languages into a separate table and added a languageid column as a foreign key to the languages table, and a new translationid column which becomes the primary key in the new content table, by which all content is referenced. Having been this route, I would definitely recommend something similar, although it sounds as though you might have a lot more work ahead. I'd recommend a languages table (which can contain not only the name of the language and a unique languageid, but also information about currency symbols, etc), then in any table which contains content you want to be language specific, add a languageid column that references that table as a foreign key. Add the initial language to the languages table and then update all of the existing content to use its languageid, then alter the languageid columns making them required. Finally add your additional languages to the table and then build your management tools in ColdFusion.
As regards cacheing -- be careful how this is done -- it's a good idea, but remember that if you cache the page in English using cfcache and there's not a languageid in the url, then the next Spanish visitor to that page will defeat the purpose of having cached it. Something you might consider if your architecture can support it without a major rewrite, is using your application to write infrequently changing layout and navigation to static files. You ought to be able to use some combination of unique identifiers from your database to name the files to ensure there aren't any conflicts. For instance, you might have something like this as a file structure: /languages/1/layout/header.cfm /languages/1/layout/footer.cfm Or if you use a unique character value for languages in your database you could have more intuitive file paths. You could of course revert them all the way back to .html, although the purpose of publishing the "static" content to coldfusion modules is so that you can retain the ability to place important bits of dynamic content (rotating banners, etc) in the headers and footers. But since the layout and navigation will have all been generated in advance, the CF Server won't have that extra workload on each request. Finally, I would recommend against using any cgi variables or geographic lookup data as the sole determination of language. Great to use this to initiate the language on the first visit, but store a language id in a session or client variable and reference that to drive the actual content so you can provide links to alternate languages. If your system provides (or enforces) a means of associating pages, you can even provide links to the same page in all available languages (Tapestry does this), i.e. product information for product x in Spanish, English, German and French. :) hth s. isaac dealey 972-490-6624 new epoch http://www.turnkey.to lead architect, tapestry cms http://products.turnkey.to tapestry api is opensource http://www.turnkey.to/tapi team macromedia volunteer http://www.macromedia.com/go/team certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 > I'm trying to do pretty much the same --- and want to know > if anyone out there has experience with multi language > mgmt- especially the pitfalls to be avoided. > The page in question on my site that needs to support 5 > languages is primarily images and little text. But most of > the text is derived from the database (drop-down menu > content etc) and my idea right now is to put my > translations in different columns in the same table. > Depending on the user's language settings (known from CGI > variable HTTP_ACCEPT_LANGUAGE)- I could substitute info > from the appropriate column- and then cache the page. > The shortcoming of this system seems to me to be > 1. Static text (HTML)- I could probably create 5 different > HTML code snippets in each language and load those the > same way. > 2. Maintaining translations for each table of concern- > Maybe an alternative could be a separate table that has > english keywords with their translations > and I could a search on a list/structure of > english-to-some-other-language key-value pairs. That way I > could separate the actual queries from the translation > itself. > Any thoughts, criticisms, words of wisdom and/or > encouragement welcome > Thanks, > Nik > [EMAIL PROTECTED] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~| > Archives: > http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 > Subscription: http://www.houseoffusion.com/cf_lists/index. > cfm?method=subscribe&forumid=4 > FAQ: http://www.thenetprofits.co.uk/coldfusion/faq > Signup for the Fusion Authority news alert and keep up > with the latest news in ColdFusion and related topics. > http://www.fusionauthority.com/signup.cfm > Unsubscribe: http://www.houseoffusion.com/cf_lists/uns > ubscribe.cfm?user=633.558.4 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
