Joshua Harvey wrote: > Hi Tim, > > Your first proposal makes a lot of sense, and should be easier if we > add a SUPPORTED_LANGUAGES = [ 'en', 'es' ] type constant. We're > thinking of adding something like that anyway for other features. Good news :)
> I didn't understand your second question. Why do you need to have > actual records in globalize_translation for a model if there's no > translation for that model in the given language? What's the > connection to view translations? My idea is to create web interface which would allow it's user to inspect and translate both already translated model data and model data which is supposed to be translated. Easy way is to reproduce example translator logic to work with all texts which appear in globalize_translations table. That's the reason I'd like to have empty records in translations table for model data that need to be translated but isn't translated yet. I see two way of reaching this effect: 1) to load empty translation records for all supported languages when new model record is created 2) to load empty records to translations table once corresponding model records have been used (it's the same way it is done with view translations). I'm not sure it's the best way to organize tranlator's interface but it's the easiest I think of. The other idea is to take records directly from model (instead of using globalize_translations as the only data source) and to save translations. Probably it's the better way. This way it would be good idea to be able to get the list of all models and all translatable attributes. Is there a way to get it all? Tim -- Posted via http://www.ruby-forum.com/. _______________________________________________ Railsi18n-discussion mailing list Railsi18n-discussion@rubyforge.org http://rubyforge.org/mailman/listinfo/railsi18n-discussion
