hi, > > I was waiting quite a long time for a proper solution of the language > dependent fields ... - an I am looking forward to the announced solution for > OXID 4.5!! :-)
+1 for a quick and clean solution. > > I also think that a single table would be enough for keeping the lang stuff. > This table should have: > - OXID -> primary key > - OXOBJECTID -> ID of according dataset, e. g. OXID of an article > - OXFIELDNAME -> name of the table field, e. g. "OXTITLE" > - OXLANG -> language id > - OXVALUE -> content of field in fitting language for performance reasons that`s quite a bad idea! it`s too abstract. and the most important fact: no possiblity to set special types of index!!!! and of course it is more complex to do filtering using where clause. a i18n-table for each table containing language dependent data is a cleaner solution (as christopher has proposed): oxlanguages: oxid oxarticles: oxid price oxarticles_i18n: oxid oxarticleid oxlanguageid title text > > By this you should be able to have as much languages as you wish and you > could store content from all sorts of tables in here. And it should be > possible to build a compatibility fallback for oxi18n class which first > checks the new table and if there is no entry there it could try the old > logic. This will cost a bit of performance but should anyway be a temporary > solution. > > But, building a new logic like mentioned above, you probably should also have > a proper oxlanguages table as well. > +1 for an oxlanguages table! thanks ps: if you really want a flexible solution, then store it in couchdb ;-) _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
