Original author: eschler (June 30, 2010 08:24:48)

The syntax used in fields.py (line 219-222) isn't compatible with Python 2.4 and will raise a SyntaxError. Since Django itself supports Python 2.4, modeltranslation should do so as well.

{{{
return getattr(instance, loc_field_name) or
(self.get_default_instance(instance) if
self.fallback_value is None else
self.fallback_value)
}}}

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=40

Original author: samuel.goldszmidt (July 30, 2009 12:49:40)

It seems that admin replacement for translated content doesn't work for
tabular inline.
All fields (text, text_de, text_es ...) appear in the tab foreignkey
edition form.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=12

Original author: [email protected] (March 19, 2010 11:22:13)

Project work without modeltranslation with runserver and apache/mod_wsgi,
with and without debug mode.
But with modeltranslation in production mode I got 500 error (see bellow).

What steps will reproduce the problem?

1. Debug mode disabled
2. Open site

What is the expected output?

Worked 2 language production site.

What do you see instead?

Error 500:
NotRegistered: The model "xxxx" is not registered for translation

What version of the product are you using? On what operating system?

Latest trunk.
Django 1.2 beta1, python 2.6.4, virualenv, mod_wsgi, apache Apache/2.2.12,
Linux (Ubuntu 9.10)

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=19

Original author: eschler (June 22, 2010 10:48:14)

ForeignKey and OneToOneField add fields postfixed with "_id" and ManyToManyField has to be accessed through the related table. Currently the raised KeyError is simply silenced. To support fallbacks properly, the decriptor has to handle these fields properly.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=36

Original author: [email protected] (June 30, 2010 13:18:52)

On django1.2 save a new fresh record in a registered model and it will raise a TypeError on the change_list view.

on utils.py build_localized_fieldname() line 31, please change

def build_localized_fieldname(field_name, lang):
return '%s_%s' % (field_name, lang.replace('-', '_'))

into

def build_localized_fieldname(field_name, lang):
return str('%s_%s' % (field_name, lang.replace('-', '_')))

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=41

Original author: carl.j.meyer (March 09, 2009 15:53:35)

There is a debugging print statement in the first line of
TranslationAdmin.formfield_for_dbfield which should be removed.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=3

Original author: [email protected] (August 20, 2010 16:17:58)

What steps will reproduce the problem?

1. Create model with django-tinymce HTMLField
2. Translate this field
3. Enable jquery tabs for translations.
4. Goto admin, create new object: Edit any language version of the field.
5. Save

What is the expected output?
Saved value for each language.

What do you see instead?
Value is not saved for any language. I have tracked request in Firebug, and I see that values of this field are not posted to the server any more.

What version of the product are you using? On what operating system?

• modeltranslation: trunk r89
• os : Win7
• django : 1.2.1
• django-tinymce: trunk r102

PS: Thanks for tabs. They keep up translation usability to the next level.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=46

Original author: [email protected] (August 26, 2009 11:05:52)

Fields generated by modeltranslation don't preserve the widget of the
translated fields, e.g. TextFields are rendered as Inputs instead of
Textareas. I patched this on my branch on launchpad [1], would be nice if
it could go into the main repository

[1]
http://bazaar.launchpad.net/~piquadrat/django-modeltranslation/trunk/revision/21

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=13

Original author: carl.j.meyer (April 09, 2010 13:42:20)

Hi. I've added support for list_editable in this commit; it's working well
for me:
http://bitbucket.org/carljm/django-modeltranslation/changeset/98f09f41bac9/

It takes the same approach as with fields/fieldsets on the edit page; turns
one list_editable column into a column-per-language.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=20

Original author: [email protected] (September 21, 2010 12:28:44)

Given en, de languages and simplest model:

class ProductCategory(models.Model):
name = models.CharField(_('Name'), max_length=80, blank=True)

When I give the value of 'Cat1' to name in default language, both name and name_en would be 'Cat1' as expected.

When I try to set value to an empty string in admin, name would stay 'Cat1'. So there is no way to erase it from admin.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=49

Original author: [email protected] (March 16, 2009 13:06:22)

I've made setup of modeltranslation as written in documntation.
On development machine everything works fine and as expected. I can add and
edit via admin interface items whose models have multilanguage fields.

Bun when trying to edit or add some such item on hosting machine, I'm
getting 'this field is required' error for original field.

Eg, if I have model:

...
class TestModel (models.Model):
title = models.CharField (_(u'title'), max_length=200)
...

registered with modeltranslation and admin all good, I'm coming up with the
error:

'title: This field is required'.

Fields for all languages are filled up. If fields are not filled,
additionally appears an error for field for default language (first in
settings.LANGUAGES) - normal behaviour here.

Actually, django displays "Please correct error below" with no error shown.

I have had to patch a bit
``contrib/admin/templates/admin/change_form.html'' template to display {{
adminform.form.errors }} to get the error message above.

At development I have python 2.5.2, at hosting - python 2.4, django 1.0.2,
modeltranslation from svn.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=5

Original author: jaap%[email protected] (June 17, 2010 19:10:48)

Reading the docs it would appear that the following will not work:

class MyTranslatedFooAdmin(FooAdmin, TranslationAdmin):
pass

From my experience however this works just fine.

After reading this section several times it becomes clear to me that you mean to warn users about admin classes implementing formfield_for_dbfield.

This section of the docs could use a rewrite telling people that in most cases subclassing the original admin and TranslationAdmin will work. Only classes implementing formfield_for_dbfield should use the work-around.

(Unless I'm mistaking...)

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=32

Original author: [email protected] (July 14, 2010 16:01:07)

What steps will reproduce the problem?

1. Create a model with a field using the HTMLField from django-tinymce
2. Register this field for translation

An exception will be raised: django.core.exceptions.ImproperlyConfigured: HTMLField is not supported by modeltranslation.

I know that HTMLField is just a TextField with a different widget (http://code.google.com/p/django-tinymce/source/browse/trunk/tinymce/models.py). To be able to translate this field I need to copy the list of STD_TRANSLATION_FIELDS to my project's settings.py as MODELTRANSLATION_STD_TRANSLATION_FIELDS and add the HTMLField.

It would be nice if there's some way to add to the list of supported fields instead of just overwriting them all.

For inspiration you could maybe look at the way South handles this http://south.aeracode.org/docs/customfields.html

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=42

Original author: [email protected] (July 19, 2010 19:23:01)

South almost works modeltranslation (except from e few bugs, which will soon be fixed I believe), but this will make it more awesome.

See the attached example_migration.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=44

Original author: [email protected] (June 29, 2010 18:25:32)

I found it useful to group the translated fields together in a fieldset to keep clutter down on models with a fair number of non-translated fields.

Here's the commit in my fork:
http://github.com/acdha/django-modeltranslation/commit/18d9341986b796588340ec00f38f320c26d0bda5

It won't touch a ModelAdmin which already has a fieldset, allowing the user to override if this is not desirable.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=38

Original author: [email protected] (December 19, 2009 08:37:43)

What steps will reproduce the problem?

1. add translation for any foreign key
2. get the message from django model validator that "Reverse query name
   for field '***' clashes ... "

I expect to have appropriate related_name argument for generated fields.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=15

Original author: federico.maggi (October 14, 2009 23:23:24)

Steps will reproduce the problem:

1. follow the InstallationAndUsage
2. add:

from django.contrib.flatpages.models import *
class FlatPageTranslationOptions(TranslationOptions):
"""
Translation of FlatPage.
"""
fields = (
'title',
'content', )
translator.register(FlatPage, FlatPageTranslationOptions)

1. python manage.py syncdb
2. visit the admin interface

Problem: fields are not translated even if title_* content_* are in the database.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=14

Original author: [email protected] (March 04, 2009 11:58:51)

I followed steps from "InstallationAndUsage" and created simple model:
>> class Test(models.Model):
>> body = models.TextField()

corresponding TranslationOptions class:
>> class TestTranslationOptions(TranslationOptions):
>> fields = ('body',)

and registered it of course:
>> translator.register(myproject.main.Test, TestTranslationOptions)

During manage.py syncdb I get this error:
"_mysql_exceptions.ProgrammingError: (1146, "Table
'myproject.django_content_type'
doesn't exist")"

However when I:

• commented 'modeltranslation' and 'myproject.main' (with Test model class)
  apps in INSTALLED_APPS settings tuple
• executed syncdb
• uncommented 'modeltranslation' and 'myproject.main'
• executed syncdb again
  Everything was ok.

So as you see modeltranslation tries to reach django_content_type table
before it is created. Am I missing something in documentation?

OS: windows vista
Python: 2.5.2
Django: 1.0-final-SVN-8991
modeltranslation: 0.1 rev.19

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=1

Original author: [email protected] (July 08, 2009 08:53:19)

I modified modeltranslation/models.py file so that "TRANSLATION_REGISTRY"
wouldn't be required on settings.py file.

With that modification, the translation.py would only be required for each
app, separately. I assume most people would prefer this.

I hope you implement this in a future release.

Thanks

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=10

Original author: [email protected] (March 11, 2009 17:27:45)

This bug was found on my dev machine using the trunk versions of
modeltranslation and Django.

I've followed the installation instructions, but made 2 changes to
configuration:
{{{
LANGUAGE_CODE = 'en'

gettext = lambda s: s # "dummy" gettext() function per Django i18n docs
LANGUAGES = (
('en', gettext('English')),
('ar', gettext('Arabic')),
)
}}}

When I run these commands through Django shell:
>>> from modeltranslation.tests import TestModel
>>> [x for x in dir(TestModel()) if x.startswith('title')]

I expected to get:
['title', 'title_ar', 'title_en']

Instead I got:
['title', 'title_ar', 'title_en', 'title_en-us']
Observe that 'title_en-us' is not a valid Python name. Also, it shouldn't
even be createad.

After some inspection I found that Django itself is probably the source of
this bug. There is a bug report http://code.djangoproject.com/ticket/8626
but it's marked as wontfix by Malcolm.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=4

Original author: [email protected] (June 29, 2010 18:27:21)

http://github.com/acdha/django-modeltranslation/commit/0fabf5dbe56845fb8d58fc4fd6429638a49a2d2f uses jQuery UI and the fieldset logic from #38 to convert the translated fields into tabs to reduce the space needed for many different languages (I have to support 7).

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=39

Original author: [email protected] (March 04, 2009 12:06:30)

"The LANGUAGES variable must contain all languages used for translation.
The first language is treated as the default language."

It's bad approach in my opinion. Any chance that you will provide in
settings.py DEFAULT_LANGUAGE constant or just use LANGUAGE_CODE as the
default lang?

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=2

Original author: [email protected] (July 16, 2010 21:30:29)

update_translation_fields has to manually duplicate data and currently does so by iterating over each object, which is inefficient with more than a few records.

The attached patch (also available at
http://github.com/acdha/django-modeltranslation/commit/4eda12cb826364d3b8e45664979c3d31ceeb9cab) changes this to use Django F objects instead, which changes the runtime from 15+ minutes to a couple seconds on my system with a couple of large datasets.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=43

Original author: [email protected] (August 16, 2010 13:29:25)

Hello,

I suggest to change model.objects.. to model._default_manager (for example I don't use default manager, but custom one)

regards.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=45

Original author: carl.j.meyer (May 22, 2010 17:35:23)

What steps will reproduce the problem?

1. Create a model with a field whose verbose_name is marked for translation
   with ugettext_lazy
2. Register that model and that field for translation via modeltranslation
3. View that model's changelist or add/change page in the admin under
   several different languages.

What is the expected output? What do you see instead?

The verbose_name for the field will always be in the default language, with
a language code in brackets appended.

I would expect that the original part of the verbose name (before the
brackets) would be appropriately translated to the current language.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=24

Original author: [email protected] (June 15, 2010 08:16:05)

For many cases it would be useful to just return empty string instead of value of default language.

Foe example, for some product we have only summary in target language and do not want to clutter page with content in other language.

This could be made as setting for TranslationOptions with default behavior as is current implementation:

class NewsTranslationOptions(TranslationOptions):
    fields = ('title', 'text',)
    default_translate = False # default is True

If you found this sensible let me know and I will create a patch.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=28

Original author: eschler (June 24, 2010 10:59:51)

Currently no error is raised if an unsupported field is registered for translation which can lead to weird and even dangerous side effects. Modeltranslation should bailout early and raise ImproperlyConfigured in case a field is not fully supported.

This could be handled by a factory which creates the translation field objects depending on the original field.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=37

Original author: carl.j.meyer (March 19, 2009 21:24:42)

What steps will reproduce the problem?

Run "./manage.py test modeltranslation" from a project with languages other
than 'de' and 'en' in settings.LANGUAGES and/or some models set for translation

What is the expected output? What do you see instead?

Tests fail, they should pass.

What version of the product are you using? On what operating system?

Most recent trunk.

Please provide any additional information below.

Attached patch fixes the problem.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=6

Original author: jaap%[email protected] (June 17, 2010 08:13:00)

What steps will reproduce the problem?

1. Have a model (foo) with a non null field (bar)
2. Register this model and field for translation
3. Try to save a new instance of this model through the admin

What is the expected output? What do you see instead?

I expect a newly saved instance

Instead an error gets raised:

IntegrityError at /admin/foo/bar/add/
foo_bar.title_it may not be NULL

What version of the product are you using? On what operating system?

This issue appears both on 0.2 and the trunk version.

Please provide any additional information below.

It works with r54. The fix for issue 26 in r55 seems to have caused this regression.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=29

Original author: [email protected] (April 28, 2010 10:58:31)

What steps will reproduce the problem?

1. add some data to table with translation fields (by admin page)
2. dumpdata to initial_data.json
3. python manage.py syncdb
4. problem below:

Python == 2.6.4
Django == 1.2 Beta 1

modeltranslation == 0.1 (Revision 51)

Problem installing fixture 'C:\cygwin\home\vaxXxa\myproject\myapp\fixtures
\initial_data.json': Traceback (most recent call last):
File "c:\Python26\lib\site-packages\django\core\management\commands
\loaddata.py", line 165, in handle for obj in objects:
File "c:\Python26\lib\site-packages\django\core\serializers\json.py",
line 42, in Deserializer for obj in PythonDeserializer(simplejson.load
(stream), **options):
File "c:\Python26\lib\site-packages\django\core\serializers\python.py",
line 1
26, in Deserializer yield base.DeserializedObject(Model(**data), m2m_data)
TypeError: init() keywords must be strings

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=22

Original author: [email protected] (July 19, 2009 10:44:50)

This is perhaps somewhat selfish, but django-modeltranslation's use of
custom, dynamically-added fields is screwing up South. Since a few people
have come to me with this issue, I'd like to try and persuade you to
implement the south_field_triple method on the custom field so South knows
how to represent it.

I've made and attached a patch that implements this method.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=11

Original author: [email protected] (September 09, 2010 10:19:16)

LANGUAGES = (
('ru', gettext('Russian')),
('en', gettext('English')),
)

MODELTRANSLATION_DEFAULT_LANGUAGE = "ru"

class Member(models.Model):
firstname = models.CharField(blank=True)

class MemberAdmin(TranslationAdmin):
pass

1. In admin I enter new Member with "Example name" firstname [ru]
2. I see "Example name" in Members list
3. I clear firstname [ru](all text inputs are clean) and save
4. I also see "Example name" as firstname.

In database clears up firstname_ru field only, but not firstname field.

django 1.2
modeltranslation rev 97
mac os

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=47

Original author: [email protected] (March 01, 2010 19:23:17)

What steps will reproduce the problem?

1. App has to be in debug mode
2. Execute: manage.py dumpdata > data.json
3. Load this data: manage.py loaddata data.json

What is the expected output? What do you see instead?
The fixture won't load because the print statement stating that:
"modeltranslation: registered x applications for translation (Model1,
Model2)"
has been saved as the first line of the json file.

I attach the modified models.py file that solves this issue.
(Well, I've simply commented the last 3 lines.)

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=16

Original author: [email protected] (March 24, 2009 20:38:55)

When I run manage.py syncd I get No translation.py found in the project directory.

content of the translation.py from the project directory:

from modeltranslation.translator import translator, TranslationOptions
from news.models import New

class NewsTranslationOptions(TranslationOptions):
fields = ('body','title')

translator.register(New, NewsTranslationOptions)

I love the idea.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=8

Original author: [email protected] (April 18, 2010 18:00:40)

What steps will reproduce the problem?

1. Create a class with a translatable title and a slug field
2. In the admin, define prepopulated_fields = {'slug': ('title', )}
3. Try to create an object

What is the expected output? What do you see instead?
I expect the admin to display the new object admin interface
But I got a KeyError on title exception

For now, I don't have the time to investigate further since I am testing django-modeltranslation.
I just removed the prepopulated_fields from the admin in order to evaluate.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=21

Original author: [email protected] (September 30, 2010 17:28:49)

What steps will reproduce the problem?

1. Make a base class A with the field title, do not mark as abstract
2. Make a class B which is a subclass of A and adds it's own fields
3. Register the title-field in class B for translation
4. Call B.objects.all()

What is the expected output? What do you see instead?
It should return all instances of B, instead it generates incorrect SQL:
'SELECT "A"."id", "A"."title", "B"."A_ptr_id", "B"."title_is", "B"."title_en", "B"."someotherfield" FROM "B" INNER JOIN "A" ON ("B"."a_ptr_id" = "A"."id")'
As a result I get an error:
Caught DatabaseError while rendering: column B.title_is does not exist...

What version of the product are you using? On what operating system?
Django 1.3 django-modeltranslation-trunk

Please provide any additional information below.
It would be great if I could just register the base class for translation, but if I try to do that I get a NotRegistered error when making queries on the inherited class.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=50

Original author: jaap%[email protected] (June 17, 2010 13:57:11)

According to a comment in TranslationField.pre_save the original translatable field's value is set to the value entered in the 'default' field.

The code in question however gets the current active language:

http://code.google.com/p/django-modeltranslation/source/browse/trunk/modeltranslation/fields.py?spec=svn68&r=68#61

This causes weirdness when you are using the admin in a language other than the default.

There are two other places where the default language is determined:

http://code.google.com/p/django-modeltranslation/source/browse/trunk/modeltranslation/admin.py?spec=svn68&r=67#37

http://code.google.com/p/django-modeltranslation/source/browse/trunk/modeltranslation/management/commands/update_translation_fields.py?spec=svn68&r=40#15

Both use settings.LANGUAGES[0][0]

I've added a patch that creates a new utility method called get_default_language

I've also updated the code where the default language is required to make use of this new method.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=31

Original author: [email protected] (May 24, 2009 08:14:15)

When using either fields or fieldsets in the admin I am getting an error:

Caught an exception while rendering: 'NoneType' object has no attribute 'label'

Without specifying fields or fieldsets admin works fine.

Using Django 1.1

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=9

Original author: [email protected] (June 17, 2010 08:40:17)

My model has a

image = models.ImageField(upload_to='u', blank=True, null=True)

and I want to translate this field (I have insert this field in the translation.py correctly).

When I save an object without an image there is no problem (the field accept blank value), but when I submit an image in one or more languages I get this error:

'unicode' object has no attribute '_committed'

/Library/Python/2.6/site-packages/django/db/models/fields/files.py in pre_save

1. if file and not file._committed:

   ---

I use django version 1.2.1 and django-modeltranslation 0.2 r57

Thanks

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=30

Original author: [email protected] (June 19, 2010 14:52:36)

What steps will reproduce the problem?
2. Create a field like title = models.CharField('Title', max_length = x)
3. Open admin interface to introduce new entry

What is the expected output? What do you see instead?
The labels should be 'Title [en]', 'Title[de]'
Instead, the labels are empty

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=35

Original author: [email protected] (September 12, 2010 00:30:50)

it will be good with this project work with django-evolution http://code.google.com/p/django-evolution

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=48

Original author: [email protected] (April 30, 2010 16:19:23)

I have one idea.
Will be cool if you add in admin page near translation field button
"Suggest", which connect to http://translate.google.com/ and grab
translation.

Django-rosetta use this method. Nice feature!

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=23

Original author: eschler (March 05, 2010 17:05:16)

Sometimes exceptions are swallowed by modeltranslation (or django itself?),
which makes debugging a pain.

The development server in this case just prints:
{{{
modeltranslation: Registered 0 models for translation ().
}}}

If an app which is registered for translation is accessed through the admin
a pretty useless NotRegistered exception is raised:
{{{
Traceback:
File "/xxx/site-packages/django/core/handlers/base.py" in get_response

1.             response = callback(request, _callback_args,
   

   *_callback_kwargs)
   File "/xxx/site-packages/django/contrib/admin/options.py" in wrapper

2.             return self.admin_site.admin_view(view)(_args, *_kwargs)
   

   File "/xxx/site-packages/django/views/decorators/cache.py" in
   _wrapped_view_func

3.     response = view_func(request, _args, *_kwargs)
   

   File "/xxx/site-packages/django/contrib/admin/sites.py" in inner

4.         return view(request, _args, *_kwargs)
   

   File "/xxx/site-packages/django/db/transaction.py" in _commit_on_success

5.             res = func(_args, *_kw)
   

   File "/xxx/site-packages/django/contrib/admin/options.py" in change_view

6.     ModelForm = self.get_form(request, obj)
   

   File "/xxx/site-packages/cms/contentmanagement/admin.py" in get_form

7.     form = super(ManagedContentOptions, self).get_form(request,
   

   obj, **kwargs)
   File "/xxx/site-packages/django/contrib/admin/options.py" in get_form

8.     return modelform_factory(self.model, **defaults)
   

   File "/xxx/site-packages/django/forms/models.py" in modelform_factory

9. return ModelFormMetaclass(class_name, (form,), form_class_attrs)
   

   File "/xxx/site-packages/django/forms/models.py" in new

10.                                   opts.exclude, formfield_callback)
    

    File "/xxx/site-packages/django/forms/models.py" in fields_for_model

11.     formfield = formfield_callback(f)
    

    File "/xxx/site-packages/django/utils/functional.py" in _curried

12.     return _curried_func(_(args+moreargs), *_dict(kwargs,
    

    **morekwargs))
    File "/xxx/site-packages/myproject/admin.py" in formfield_for_dbfield

13.     field = super(TranslatedFooAdmin,
    

    self).formfield_for_dbfield(db_field, **kwargs)
    File "/xxx/site-packages/cms/modeltranslation/admin.py" in
    formfield_for_dbfield

14.     self.patch_translation_field(db_field, field, **kwargs)
    

    File "/xxx/site-packages/cms/modeltranslation/admin.py" in
    patch_translation_field

15.     trans_opts = translator.get_options_for_model(self.model)  
    

    File "/xxx/site-packages/cms/modeltranslation/translator.py" in
    get_options_for_model

16.         raise NotRegistered('The model "%s" is not registered
    

    for translation' % model.name)

Exception Type: NotRegistered at /admin/core/foo/3/
Exception Value: The model "Foo" is not registered for translation
}}}
The Exception which is source of the problem becomes swallowed.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=17

Original author: carl.j.meyer (May 29, 2010 07:30:41)

What steps will reproduce the problem?

1. Create a model with a prepopulated field whose value is derived from an
   untranslated field
2. Add an (unrelated) translated field to that model
3. Make its ModelAdmin subclass derive from TranslationAdmin

What is the expected output? What do you see instead?

The admin pages for that model are broken because the prepopulated_field
support in TranslationAdmin does not check whether the field is actually
translated or not.

Fix is here: http://bitbucket.org/carljm/django-
modeltranslation/changeset/50086e826fa7

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=25

Original author: jaap%[email protected] (June 17, 2010 21:22:50)

Using a language other than the default language for the admin can lead to empty or 'ghost' values in the original translatable field.

With a setup like this:

LANGUAGE_CODE = 'nl'
LANGUAGES = (
('en', _('English')),
('nl', _('Dutch')),
('de', _('German')),
)

class Sample(models.Model):
name = models.CharField(max_length=255)

def unicode(self):
return self.name

Having registered Sample.name as translatable and using TranslationAdmin as the admin class.

I'm encountering the following issue:

1.) Add a new 'sample' and enter only a value for the default field (Name [en]). I'm expecting the unicode method to return the value of name_en. Instead it returns an empty string, as shown by the empty entry in the changelist.

This seems to be caused by sample.name being set to the value of sample.name_nl (the active language).

2.) Edit the newly saved instance (you can click on the white space where the name would be, or manipulate the url).

Enter a value for Name [nl] and save again. unicode will now return the value you entered for Name [nl]. This is expected because nl is the active language. name_en still holds the value entered in step 1, also as expected.

3,) Edit the instance one more time. This time blank out the Name [nl] field and save. unicode will now show the value just deleted from Name [nl]. The expected result would be to show the value of name_en.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=33

Original author: [email protected] (June 10, 2010 21:04:46)

If you have a field which has unique=True set django.contrib.admin will trigger form validation warnings ("<Model> with this <field> already exists") when someone leaves the translated field blank.

This was trivially solved by adding a get_db_prep_value (added in Django 1.2) to TranslationField which converts empty strings to None:

http://github.com/acdha/django-modeltranslation/commit/e95d5cfb2d71ec5dcd3cf05bf14963a2c19f9e43#L0R65

It looks like this should be seamless since the fields are always declared as blank/null and the test suite passes with this change.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=26

Original author: [email protected] (June 14, 2010 14:34:28)

While evaluating django-multilingual-ng and django-modeltranslation-ng I created two minimal apps to test and demo admin integration for both of them.

I belive it can be of interest to other developers, for same reasons.

username and password are "demo"

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=27

Original author: eschler (March 05, 2010 20:51:01)

Add support for generic admin inlines (GenericTabularInline,
GenericStackedInline).

Since svn is readonly at the moment, i've attached a patch.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=18

Original author: jaap%[email protected] (June 18, 2010 19:51:07)

What steps will reproduce the problem?

1. Mark a non text field for translation (IntegerField will work)
2. Enter invalid data into the field.
3. Save the model

What is the expected output? What do you see instead?
I expected a validation error about entering invalid data. Instead the model (tries to) save the data without warning.

What version of the product are you using? On what operating system?

I'm using the trunk version (r69) with django 1.2.1.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=34

Original author: [email protected] (March 21, 2009 20:29:48)

What steps will reproduce the problem?

1. Use django-modeltranslation in django project
2. Try to deploy it using apache and mod_wsgi
   Server will return status code 500 and "IOError: sys.stdout access restricted by mod_wsgi" message.

See http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Writing_To_Standard_Output

I think this behaviour should be documented or fixed.

Original issue: http://code.google.com/p/django-modeltranslation/issues/detail?id=7