google-code-export / django-modeltranslation

Automatically exported from code.google.com/p/django-modeltranslation
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

App level translations #71

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
First hand, this is a little more than a feature proposal since it would break 
the backward compatibility .. Maybe it's possible to avoid burning the bridge, 
but I haven't explored this possibility.

Modeltranslation is really a great tool to handle multiple languages in 
database. However the way the registry works really bothers me because it 
implies creating a new translations.py for each project and and it leads to 
lots of code duplication.

A couple of months ago I found a for of this project on github which is tweaked 
to do exactly what I wanted. Instead of a project level translations.py it use 
app level translations.py. So now I just have to drop-in my reusable django 
apps and the translation works right away.

The original fork:
https://github.com/hyperweek/django-modeltranslation

The my fork of the above fork:
https://github.com/h3/django-modeltranslation

The difference with my fork is that I merged the latest changes from you repos 
in it.

The only thing I would add is a mechanism (probably a settings) to exclude some 
apps from being translated automatically.

Original issue reported on code.google.com by hainea...@gmail.com on 10 Apr 2012 at 6:49

GoogleCodeExporter commented 9 years ago
This a duplicate of issue 10.

I am positive about changing modeltranslation to use per-app level 
translations. The historical design decision to have a project wide was 
probably not the wisest one. It just has to be assured that an app can be 
unregistered in a similiar way as an admin app.

After a (short) look at your fork, resp. the hyperweek's one, i see a few 
problems:

1) It seems to contain several other features. A patch which applies only the 
per-app level translation would be handy.
2) 23 of 28 tests fail. Now this a big one. Either the tests have to be 
updated, or some features are actually broken.
3) As you said it breaks backwards compatibility, but i don't consider this a 
real problem. Just has to clear in the documentation.

Original comment by eschler on 15 Apr 2012 at 11:14

GoogleCodeExporter commented 9 years ago
Closed issue 10 in favour of this.

Original comment by eschler on 10 May 2012 at 8:36

GoogleCodeExporter commented 9 years ago
Issue 10 has been merged into this issue.

Original comment by eschler on 10 May 2012 at 8:37

GoogleCodeExporter commented 9 years ago

Original comment by eschler on 7 Jul 2012 at 12:07

GoogleCodeExporter commented 9 years ago
The recently released django-modeltranslation-wrapper by Jacek Tomaszewski 
implements per app translations on top of modeltranslation and keeps backwards 
compatibility.

I'm planning to merge this feature for 0.5. But the autodiscover should be 
triggered in urls.py like Django's admin does to prevent race conditions as 
reported in issue 19 and issue 56.

http://pypi.python.org/pypi/django-modeltranslation-wrapper/1.0

Original comment by eschler on 7 Jul 2012 at 12:18

GoogleCodeExporter commented 9 years ago
Decided to take this into the 0.4 release cycle, which will start with an alpha 
release to test the new features.

Original comment by eschler on 10 Jul 2012 at 3:29

GoogleCodeExporter commented 9 years ago

Original comment by eschler on 10 Jul 2012 at 9:16