We are building a site which offers different product mixes depending on where in the world you live, eg there are products applicable to the USA, Canada, Europe and Asia. So visitors to the site must choose their region when they arrive at the site. Then we want to offer them choices of language, no matter what the region. So you could choose French even if you live in Japan, or Japanese even if you're in the US. My initial db schema simply has a resource table which stores multiple versions of all text from my product and other tables. So my product table would simply reference the resource table for the product name, for example. Language could be stored in a session variable or in the URL. I don't see any problems with this approach for the front-end stuff, but I'm worried that Rails may not be able to autogenerate all my back-end scaffolding. Do either of GLoc or Globalize assist with what I'm doing? Could anyone share their experiences. Thanks Nick.
on 2006-06-01 21:04
on 2006-06-02 10:20
> My initial db schema simply has a resource table which stores multiple > versions of all text from my product and other tables. So my product > table would simply reference the resource table for the product name, > for example. Language could be stored in a session variable or in the > URL. Globalize has *one* translation table. You're handling the different languages by switching the locale. You have to specify which model attributes you want to have translated. The original models have the default language as an attribute. Didn't play with fall-back scenarios (in case you don't provide a translation), but I guess that the default language is used for that. Since the translation all go into a generic attribute table (or however you call that) I'm not sure sure about performace impact. Don't know if caching mechanism come into play. Didn't take a look at GLoc yet. But since the authors of both projects reading this list, they can answer more precise.