Re: I18N for PEAR (before Language class for PEAR?)

> I'm becoming very interested in multi-language frameworks for web > applications (as I should be, the web is supposed to be universal :)). Indeed :) > For example, say a products table had these fields: > > id, title, price, description > > Is it more effective to create a products_en, products_fr, etc. table or > to duplicate just the necessary fields, ie. > > id, title_en, title_fr, price, description_en, description_fr The above is what gets people into trouble. You need to create another entity: product id title_id description_id price product_title id title lang product_description id description lang There is no way around increasing the complexity of your database schema. (or I suppose there is if you are happy to run completely separate installations for each locale... and there are some cases where that works) > Or is there any other way of handling this? And what would be the > issues involved in managing duplicate tables, etc.? The way we will handle that sort of stuff in binarycloud is to gave the system generate all "standard" queries which will take much of the workload off the developer. For example, the additional "product_title" fkey above in the product table would be incorporated into the default queries of the "product" entity in binarycloud, so you wouldn't actually care that there's another table :) That will help to reduce the headache of building localization aware applications... but it still requires a great deal of thought in the design process. there are of course other localization issues besides language: -address formats -currency -measurement formats -charset (a major issue in database systems) -etc... but language tends to be the most complex because it requires these kinds of schema extensions. Addresses aren't really _that_ different throughout the world, so you can store the data in a single entity. _alex