label_for_filter is too quick to force labels to str

[interDist]

As a result, the labels are evaluated as soon as the form class is generated, in the locale context of the code that causes this generation – and not at the point of output. By the time the form is rendered (maybe in a different locale) it is already too late, with labels having already lost their laziness.

[carltongibson]

Hi @interDist — this seems reminiscent of #765. Can you have a read there and see what you think?

I'm going to convert to a discussion for now. We can convert back if we can pin down something concrete/actionable.

[interDist]

I went over that ticket/discussion. Ryan’s comment suggests that there is an issue with translation; I think that the translation works properly but the underlying cause is that the translations are evaluated too early (within the label_for_filter by using force_str). In my case, the form’s fields are injected by the FilterSet based on their definitions in the model, which include localized labels.

Basically, when the form’s widgets are rendered, their labels are already a str and not a django.utils.functional.lazy.<locals>.__proxy__.

In my opinion, the solution would be to convert the join and capfirst operations to lazy ones, which would keep the labels themselves lazy for as long as possible.

[interDist]

In my view, early on, I have the following: self.place_filter = SearchFilterSet(request.POST, self.queryset, request=request). I think that already at this stage, the form is generated and the labels are evaluated (forced to str). By the time get_context_data is called, for example, the form is already ready for use. Doesn't this violate the principle that the labels should be kept lazy until the point of output?

[carltongibson]

Hi @interDist — The labels are not generated until you access the .form property, which is built dynamically:

django-filter/django_filters/filterset.py

Lines 261 to 269 in dbc69e7

	@property
	def form(self):
	if not hasattr(self, '_form'):
	Form = self.get_form_class()
	if self.is_bound:
	self._form = Form(self.data, prefix=self.form_prefix)
	else:
	self._form = Form(prefix=self.form_prefix)
	return self._form

)

If you set the active language before accessing this, your labels should be translated. This timing would apply to any Django Form I think — it's not django-filter specific, I think 🤔

[interDist]

All right, I see now what happens. In my view’s get_context_data I do access the form property to do a calculation of the filters which are being applied. That is the point the labels are getting translated. As a side note, it is different from the behaviour of other (standard) forms; I know that because I have tests specifically geared towards i18n – in those tests, I first initiate a form manually, then access the label properties under the context of a specific language (using with override_settings(LANGUAGE_CODE='xx')). It works for the standard forms but not for the form generated through the FilterSet...

By the way, my code to calculate the active filters is

        context['filtered_by'] = (
            set(form.changed_data).intersection(
                f for f, v in getattr(form, 'cleaned_data', {}).items() if v)
        ) if form.is_bound else []

Is there a better way? Maybe the FilterSet has a method that would return the same information?

[carltongibson]

If we were to have a method it would likely go via form.cleaned_data... (Refs #717) — but that clearly wouldn't solve your problem.
You could use request.GET.keys() directly, but then you loose the form validation.

What I'm not seeing is why you're needing to generate the form before setting the language? 🤔

It works for the standard forms but not for the form generated through the FilterSet...

Can show me a test case that sets the language before generating the form, and localises the labels incorrectly?

[interDist]

I guess in a real setting, the language is always configured before the FilterSet’s form is generated. My tests (until now) were creating forms, testing them, and then using override_settings(LANGUAGE_CODE='xx') to test for localisations. This always worked for Django forms and was the reason I was surprised about the behaviour of the FilterSet, all the more django-filter is maintained by Django core dev – so I assumed the same principle (keep things lazy until they are actually output) would apply.

One scenario that comes to mind is if the view generates the form (for example, in get_context_data) and the output is performed within a {% language 'xx' %} block, where xx differs from the default language. Maybe it is a contrived example...