mirror of
https://github.com/Hopiu/django-modeltranslation.git
synced 2026-05-09 22:04:48 +00:00
Translates Django models using a registration approach.
b06e49921b
in the tabbed admin script. Javascript has a nasty semantic of moving initializers to the beginning of a block, thus rewritting ``var a = a || b`` as ``var a; a = a || b``. With such a code, if ``a`` starts as a global variable with some value, you could think that it would end up having the same value, but it is actually first set to ``undefined`` at the beginning of the block and then always set to ``b`` in the statement [1][2]. This is mostly of importance if you actually have more than one jQuery loaded. For instance, this happens with Mezzanine -- first Grappelli-safe loads a copy, and calls ``$.noConflict`` thus storing its version as ``jQuery``, second is Django, loading another copy and calling ``django.jQuery = jQuery.noConflict(true)``. So far so good, we have one copy on ``jQuery`` and another on ``django.jQuery``; jQuery UI chooses to load itself onto the ``jQuery`` (Grappelli) copy. But now runs the tabbed_translation_fields script, hiding the jQuery with UI loaded at the very beggining of the first block, and a moment later complaining that ``.tabs()`` or something else is not defined. [1]: http://www.ecma-international.org/ecma-262/5.1/#sec-12.2 (note the first paragraph after the grammar) [2]: http://stackoverflow.com/questions/500431/what-is-the-scope-of-variables-in-javascript (point 8) |
||
|---|---|---|
| docs/modeltranslation | ||
| modeltranslation | ||
| .gitignore | ||
| .travis.yml | ||
| AUTHORS.rst | ||
| CHANGELOG.txt | ||
| LICENSE.txt | ||
| MANIFEST.in | ||
| PKG-INFO | ||
| README | ||
| README.rst | ||
| runtests.py | ||
| setup.py | ||
| tox.ini | ||
| travis.py | ||
================
Modeltranslation
================
The modeltranslation application is used to translate dynamic content of
existing Django models to an arbitrary number of languages without having to
change the original model classes. It uses a registration approach (comparable
to Django's admin app) to be able to add translations to existing or new
projects and is fully integrated into the Django admin backend.
The advantage of a registration approach is the ability to add translations to
models on a per-app basis. You can use the same app in different projects,
may they use translations or not, and you never have to touch the original
model class.
.. image:: http://img.shields.io/travis/deschler/django-modeltranslation/master.png?style=flat
:target: https://travis-ci.org/deschler/django-modeltranslation
.. image:: http://img.shields.io/coveralls/deschler/django-modeltranslation.png?style=flat
:target: https://coveralls.io/r/deschler/django-modeltranslation
.. image:: https://pypip.in/v/django-modeltranslation/badge.png?style=flat
:target: https://pypi.python.org/pypi/django-modeltranslation/
:alt: Latest PyPI version
.. image:: https://pypip.in/py_versions/django-modeltranslation/badge.png?style=flat
:target: https://pypi.python.org/pypi/django-modeltranslation/
:alt: Supported Python versions
.. image:: https://pypip.in/d/django-modeltranslation/badge.png?style=flat
:target: https://pypi.python.org/pypi/django-modeltranslation/
:alt: Number of PyPI downloads
Features
========
- Add translations without changing existing models or views
- Translation fields are stored in the same table (no expensive joins)
- Supports inherited models (abstract and multi-table inheritance)
- Handle more than just text fields
- Django admin integration
- Flexible fallbacks, auto-population and more!
Project Home
------------
https://github.com/deschler/django-modeltranslation
Documentation
-------------
https://django-modeltranslation.readthedocs.org/en/latest
Mailing List
------------
http://groups.google.com/group/django-modeltranslation