Django

Code

Ticket #3600 (closed: fixed)

Opened 2 years ago

Last modified 2 years ago

Newforms label translation fails

Reported by: Timo Assigned to: adrian
Milestone: Component: Forms
Version: SVN Keywords: newforms translation internationalization
Cc: Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 1

Description

Newforms' labels can be translated with gettext during initialization. 

class TestForm(forms.Form):
    name = forms.CharField(label=capfirst(_('name')), max_length=255)

But this works only at first time. If you want to change your language during session ('/i18n/setlang/') the labels are not translated to the new language you are requesting.

Attachments

newforms_translation_fix.patch (1.9 kB) - added by karsu on 03/19/07 09:35:21.
Newforms label and help_text translation patch
newforms_translation_fix_tests.patch (0.9 kB) - added by akaihola on 03/19/07 17:15:08.
Test which fails before the above patch and succeeds with it

Change History

03/19/07 08:19:59 changed by karsu

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

Problem is the same if you use gettext_lazy

03/19/07 08:22:42 changed by anonymous

views.py 

from django.utils.translation import gettext_lazy
from django.shortcuts import render_to_response
from django.template import RequestContext
from django import newforms as forms

class TestForm(forms.Form):
    first_name = forms.CharField(label=gettext_lazy('First name'), help_text=_('First name'))
    last_name = forms.CharField(label=gettext_lazy('Last name'), help_text=_('Last name'))

def test(request):
    form = TestForm() 

    return render_to_response('test.html', RequestContext(request, {
        'form': form,}))

test.html 

{% load i18n %}
<html>
    <head>
        <title>bug</title>
    </head>
    <body>
        <form  action="/i18n/setlang/?next=." method="get"><b>{% trans "language"%}:</b>
            <select onchange="this.form.submit();" name="language">
                <option value="">-------</option>
                <option value="en">{% trans "English" %}</option>
                <option value="fi">{% trans "Finnish" %}</option>
            </select>
        </form>
        <h1>{% trans "user" %}</h1>
        <table>
            {{ form }}
        </table>
    </body>
</html>

settings.py 

   'django.middleware.locale.LocaleMiddleware',

urls.py 

(r'^i18n/', include('django.conf.urls.i18n')),

03/19/07 09:35:21 changed by karsu

  • attachment newforms_translation_fix.patch added.

Newforms label and help_text translation patch

03/19/07 09:36:02 changed by karsu

  • has_patch set to 1.
  • needs_tests set to 1.

03/19/07 17:15:08 changed by akaihola

  • attachment newforms_translation_fix_tests.patch added.

Test which fails before the above patch and succeeds with it

03/19/07 17:18:43 changed by akaihola

  • needs_tests deleted.

The tests patch above adds a single simple test case for forms field with translated labels.

03/20/07 00:50:57 changed by Simon G. <dev@simon.net.nz>

  • stage changed from Unreviewed to Ready for checkin.

03/31/07 04:58:39 changed by mtredinnick

  • needs_better_patch set to 1.
  • stage changed from Ready for checkin to Accepted.

I'm not happy with this patch. It fixes the symptom, but not the cause of the problem. We want to be turning things into unicode as early as possible, so doing it in the Field class is the right thing. Moving the unicode conversion until later is inconsistent and leaves us with multiple encodings floating around internally -- something we are trying to slowly get rid of. A better fix is to work out why we aren't then translating that unicode value, which is, I suspect a deeper problem.

This is a genuine bug and the test case is good to have, but it isn't the right fix. I want to dig a bit deeper into this before committing anything.

04/02/07 05:39:06 changed by karsu

It is good idea to put unicode to Field class!

I have tried to underestand that translation problem. I have noticed if I create new instance from SomeForm? class only at first time it defines 'base_fields'. Now if you have some "dynamic" data in form class for example: translation, choices etc, all Fields datas will be generate to "static". Once a new instance from SomeForm? is created base_fields are copied and their "old" data is used while generating data to create new form fields.

Test case for ChoiceField? dymanic data 

from django.db import models
class City(models.Model):
    name = models.CharField(maxlength=100)

form_tests = r"""
>>> from django.newforms import *

>>> def get_all_cities():
...     for i in City.objects.all():
...         yield (i.id, i.name)

>>> c = City.objects.create(name="Helsinki")
>>> c.save()
>>> c = City.objects.create(name="Lahti")
>>> c.save()

>>> class CityForm(Form):
...     cities = ChoiceField(choices=get_all_cities())

>>> f = CityForm()
>>> print f.as_p()
<p><label for="id_cities">Cities:</label> <select name="cities" id="id_cities">
<option value="1">Helsinki</option>
<option value="2">Lahti</option>
</select></p>

>>> c = City.objects.create(name="London")
>>> c.save()

>>> print [(city) for city in get_all_cities()]
[(1, 'Helsinki'), (2, 'Lahti'), (3, 'London')]

>>> f = CityForm()
>>> print f.as_p()
<p><label for="id_cities">Cities:</label> <select name="cities" id="id_cities">
<option value="1">Helsinki</option>
<option value="2">Lahti</option>
<option value="3">London</option>
</select></p>
"""

__test__ = {
    'form_tests': form_tests,
}

if __name__ == "__main__":
    import doctest
    doctest.testmod()

04/02/07 05:53:06 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

(In [4904]) Fixed #3600 -- Made smart_unicode respect deferred evaluation in the case of strings translated with gettext_lazy and friends.

Add/Change #3600 (Newforms label translation fails)




Change Properties
Action