This is not exactly what I need. this library is not done as per the common best practices for i18nlizing data.
All you have to do is declare an object (field) as an i18n field and the engine takes care of the rest. This example you can see in java struct and php symphony, when executing the equivalent for syncdb it will generate an additional table which holds the i18n languages instead of creating columns with prefixes and suffixes. Having columns mapped to a specific language means modifying your table in the future if you need additional languages. Meanwhile, if creating a one to many relation with a specific table that holds only the variable in different languages means you can add as many language support as you need, Plus, when I went through polyglot it does override a lot of crucial functions, adding up such plugin into a critical production environment can be risky with very little information about it. Any other solutions? On Fri, Jan 7, 2011 at 6:25 PM, Marcos Moyano <marcosmoy...@gmail.com>wrote: > I've worked on/with this app > https://github.com/Anue/django-polyglot/ > > Hope it helps. > Rgds, > Marcos > > On Fri, Jan 7, 2011 at 12:20 PM, Mo Mughrabi <mo.mughr...@gmail.com>wrote: > >> Hello, >> >> in my design there are some models where I need to store certain fields in >> different languages. I was wondering if anyone has done it before? I saw >> some django modules that help do model translations but some of them did not >> work properly. >> >> Any best practices out there? below is my code >> >> *my model.py* >> >> class Lookup_I18n(models.Model): >> i18n_code = models.CharField(max_length=5, >> default=settings.LANGUAGE_CODE) >> value = models.CharField(max_length=300) >> >> class Lookup(models.Model): >> >> purpose = models.CharField(max_length=10) >> key = models.CharField(max_length=10) >> value_i18n = models.ForeignKey(Lookup_I18n) >> value = models.Field() >> >> class Meta: >> unique_together = (('purpose', 'key'),) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> > > > > -- > Some people, when confronted with a problem, think “I know, I'll use > regular expressions.” Now they have two problems. > > Jamie Zawinski, in comp.emacs.xemacs > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
