On Jul 11, 6:16 pm, Marc Garcia <[EMAIL PROTECTED]> wrote:
> I've designed an admin page with my
> idea:http://vaig.be/2007/07/11/django-database-texts-translated/
I link this Idea a lot in principal and think it would be easier to
maintain than other solutions I have seen (at first blush).
I have seen something like this done with the sites framework, where
each site (at a different host like en.foo.com and es.foo.com) were
for the corresponding language. Each model with language specific text
had a site FK. The save() methods were overwritten to save the changed
fields which were not site specific to the other site instances in the
DB. this was a huge effort, and it meant that there were separate
admin interfaces for each language (which were also in their target
language). A middleware was used to send the person to the selected
language site. This ended up being a bear to maintain. From that
experience I have felt that just using custom .po's and .mo's was a
better way to go.
You are making me rethink this problem again.
What you are describing could be implemented with new types of
CharField and TextField fields which are in fact multiple fields/
columns in the DB. Something like FileField/FileInput and ImageField.
They would use the settings LANGUAGES option to determine what and how
many other fields there are (with a huge documentation warning that
changing it could mean having to rebuild your DB schema).
One nice side effect is it would be that once this is done, you would
be able to easily make a .po set editor in django!
The initial version of this could be done as a third party addon as
well. There might be some issues with DB back ends that I have not
thought of, but I doubt it.
What this entails:
1. new MultiLangTextField and MultiLangCharField # might be a
minor max length issue here
2. newforms fields and widgets for them
3. admin template extensions for them
4. not sure how validation would work, would depend on the
widgets.
The really adventurous could implement i18n lookups to auto-fill the
languages which are left empty.
This is not simple work, but I think it can be done, and without
changing the django core. If it works well, it can be incorporated as
a contrib of rolled in later.
-Doug
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
