Hi Tomas, i'm using transmeta in my project. But in the way you are/want. Just using it to translate some short strings (and longer in FAQ). And there's no problem to add another language inproduction server (see manage.py help for more info)
Radovan http://www.yau.sk On 8. Júl, 18:56 h., Tomáš Ehrlich <tomas.ehrl...@gmail.com> wrote: > Hi there, > I just want to open discussion about this topic again, because I > didn't find any solution which 100% fits my needs. > > What I want: > - store translations in other table (1:N) > - storing additional info, if necessary (translation_date, > translation_edit_date, translator_name, etc) > - keeping the original model API with additional methods (missing > translations, translations count, etc) > - group permissions for translators > - per-site fallback language > > Before developing my own library, I was searching this mailing list > and > found:http://code.google.com/p/django-transmeta/http://code.google.com/p/django-multilingual/ > > I don't like transmeta with it's column_ln idea. Problems are: > - translating big columns (like text column) > - adding another language on production server > > Multiligual app looks better but it lacks documentation. > > Does anyone use one of these (especially multilingual app) in > production? > > ======== > My idea is: > > # Create model as usual with specific Meta options > class Article(model18n.Model): > pub_date = models.DateField() > category = models.ForeignField() > title = models.CharField() > slug = models.SlugField() > content = models.TextField() > > class Meta: > translate = ('title', 'slug', 'content') > translate_with = ArticleTranslate # optional specification of > translation model > > # Specify translation model, if necessary > class ArticleTranslate(model18n.Translations): > # id, foreign_id, lang, title, slug, content are created > implicitly > date_translate = models.DateField() > translator = models.ForeignField() # user who done translation > > These two models will create: > CREATE TABLE "articles_article" ( > "id" serial NOT NULL PRIMARY KEY, > "pub_date" date NOT NULL, > "category_id" integer NOT NULL, -- not sure about proper syntax, > nevermind > ) -- yes, translated field are not in primary table. This table keeps > only structure and common data > > CREATE TABLE "articles_article_translate" ( > "id" serial NOT NULL PRIMARY KEY, > "article_id" integer NOT NULL, > "title" varchar(5) NOT NULL, > "date_translated" date NOT NULL, > "translator" integer NOT NULL, > "title" varchar(200) NOT NULL, > "slug" varchar(200) NOT NULL, > "content" text NOT NULL, > ) > > And working with them is like usual: > > >>> article = Article(content="Dummy text", title="Dummy title", ...) # > >>> creates default language entry > >>> article.save() > >>> article.add_language("cs", content="Textovy obsah", title="Textovy > >>> nazev", ...) > >>> article.save() > ... > >>> article = Article.objects.all() # implicitly join default language > >>> article.content > Dummy text > >>> translation.activate('cs') > >>> article.content # call another SQL query > > Textovy nazev > > Reasons for this are: > - usually you need select from table only one language (only in admin > you need to select all related languages) > - separating data structure from translated content > > Problems are: > - language variants - you are translating for en_US, en_GB, default > (fallback) language is cs_CZ. When US user access model entry only > with en_GB and cs_CZ, there shoudl be fallback to en_GB, rather than > cs_CZ. Query should respect ACCEPT_LANGUAGE preferences. For now, I > don't have idea how to solve this with "single" query. > > ======= > Summary: > > 1. Does anyone use transmeta or multilingual (especially multilingual > app) in production? > 2. How are you translating models? > 3. What do you think about my solution? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
