translations...

[ashley]

after searching and reading all the posts related to internalization
and multilanguange, my first question is if there is any active
development to integrate or make easy translations in the django core,
and if not, if there are any people who would be interested in a joint
effort.

in my experience, this is one of the most difficult, but necessary
functionality in every CMS or framework.
first, the complexity of the usage cases, i identify at first hand the
following major differences:

a) a site with one main language that offers translations of all or
some of their content.
these normally have a page like www.example.com/about that offer a link
to change language where you read the about page but in another
language.

b) sites that are multilangual but are not necesarily a translation of
one language to another.
this sites may have different structure and content, mostly offering
the multilanguage capability in the url or domain:
en.example.com / es.example.com or even www.example.com /
www.ejemplo.com :)
or... www.example.com/es/informacion / www.example.com/en/about and so
on...

there are already middlewares out there that pretty much cover case b),
except for model creation etc...
case a) seems to be a little more complicated.

now i am going to describe how it should/could be for a programmer,
independently of how this could be implemented behind the scenes, in a
DRY way:

class Page(models.Model):
titel = models.CharField(maxlength=200)
text = models.TextField()

class Admin:
pass

class Translation:
pass

At this point, the model Page should already have multilanguage
capabilities.
when accessing the Admin interface, and create a new Page, in the Page
Form there could be a dropdown allowing you to choose from the
languages you have defined in settings.py. Next to that dropdown, you
have a link (add translation) that saves the current Page and redirects
to a new page form to add a translation. Next to the <add translation>
link in Page Form, you have links to all translations that already
exist: <de> <en>

Then we could expand functionality allowing the following example:

class Page(models.Model):
title = ....
text = ....
date = models.DateTime...
publish = models.Boolean.. .

class Admin:
pass

class Translation:
self.fields = (title, text)

Some times there are fields that really don't need to be translated (at
the model level), like date or a boolean.
so you can specify what fields should be translated to avoid redundant
database usage.

The examples above allow you to create a root document in any language,
so up till now it is usable for both case a) and b). Lets say you want
to force the users to create a french language always, and then allow
translations of other languages...

.....

class Translation:
....
self.root = ('fr',)

users may only create "original" documents in french, other languages
may not be "parent" Pages

or maybe just a default

class Translation:
....
self.default = 'en'

or maybe not even allowing a document to be created without creating
the translations...

class Translation:
....
self.force = ('fr','en')

so now the Page and the translation fields are on the same screen and
must be created at once.

The functionality can go on and on... different options on how the
translation forms in the admin interface can be shown (like field next
to translation field, or first all language elementes in french and
then all the english ones.. etc...)...

What functionality do we need in the views?

when we would use something like:

>>pages = Page.objects.all()

we would use:

>>pages = _lang(Page.objects.all())
(and would filter out all other languages than the current one (from
request or cookie or whatever)

_lang can accept a language to force a specific one...

>> pages = _lang(Page.objects.all(),'en')

(get the english ones....)

>>pages = _rootlang(Page.objects.all(),)

get root is similar to _lang, except that it returns the list of the
translations that exist for the root languange.
in the example above, we set root to french. _rootlang will search all
the french pages, get the translations for those documents. if you
want, it can return the original root languange version automatically
when no translation for it exists...

well, this is an original draft idea and needs some refinment, but from
the user perspective, both as an application user or as the programmer
using the framework, it would seem to me that this approach would be
intuitive and adheres to the DRY philosophy.

Now.... how this is IMPLEMENTED... is another story :D
maybe it would be good to be able to choose between: one table for
"translation relationships" and all languanges of a model is stored in
one table, or one table per translation, i think these are things that
might depend on the application, so maybe it would be nice if we could
choose:

class Translation:
self.backend = "contrib.translation.manytables...."

or something like that, and everything else is transparent
independently of how it is implemented at the database level.

well, what do the django experts around here think? i do believe that
all we who work on multilanguage sites should team up and work in a
good solution instead of 100x hacks all around :)

btw, i can't create new topics with my normal account :(
good night :)
ashley

[ashwoods]

hmm... i guess everybody is tired of translation discussions.... :)

On Jan 21, 1:12 am, "ashley" <stuff4...@googlemail.com> wrote:
> after searching and reading all the posts related to internalization
> and multilanguange, my first question is if there is any active
> development to integrate or make easy translations in the django core,
> and if not, if there are any people who would be interested in a joint
> effort.
>
> in my experience, this is one of the most difficult, but necessary
> functionality in every CMS or framework.
> first, the complexity of the usage cases, i identify at first hand the
> following major differences:
>
> a) a site with one main language that offers translations of all or
> some of their content.

> these normally have a page likewww.example.com/aboutthat offer a link

> to change language where you read the about page but in another
> language.
>
> b) sites that are multilangual but are not necesarily a translation of
> one language to another.
> this sites may have different structure and content, mostly offering
> the multilanguage capability in the url or domain:
> en.example.com / es.example.com or evenwww.example.com/www.ejemplo.com:)

> or...www.example.com/es/informacion/www.example.com/en/aboutand so

> >>pages = _lang(Page.objects.all())(and would filter out all other languages than the current one (from

> request or cookie or whatever)
>
> _lang can accept a language to force a specific one...
>

> >> pages = _lang(Page.objects.all(),'en')(get the english ones....)
>
> >>pages = _rootlang(Page.objects.all(),)get root is similar to _lang, except that it returns the list of the

[Don Arbow]

On Jan 22, 2007, at 12:22 PM, ashwoods wrote:
>
> hmm... i guess everybody is tired of translation discussions.... :)

You might have better luck in the Django internationalization group:

http://groups.google.com/group/django-I18n/

Don

[ashwoods]

ohhhhh. a group just for that :)

thx don.

On Jan 22, 9:37 pm, Don Arbow <don...@nwlink.com> wrote:
> On Jan 22, 2007, at 12:22 PM, ashwoods wrote:
>
>
>

> > hmm... i guess everybody is tired of translation discussions.... :)You might have better luck in the Django internationalization group:
>
> http://groups.google.com/group/django-I18n/
>
> Don

[marcin.k...@gmail.com]

Okay, I noticed this thread literally seconds after creating my own
describing a very similar approach. I searched the group for
'multilingual',
should also have checked 'translations'. The new thread should appear
shortly.

My library also uses the internal Translation class, but I moved the
definitions of translatable fields into Translation. I thought about
adding multiple backends too (another useful backend is to have the
translated field values in different columns in the model, so that you
can get all translations as a single row from a SELECT statement,
otherwise using translations for ordering gets tricky).
I planned to use different names instead of Translation to specify
which backend to use, but I do like the backend field.

Anyway, it's good to see I'm not the only one interested in working
on a generic solution :)

-mk

[ashwoods]

to many threads open with same topic. this thread will now be discussed
HERE:
http://groups-beta.google.com/group/django-users/browse_thread/thread/6a96426735ffd7f1