Fallback to default language if field is empty

[selwin]

Hello,

I use linguo in a project where not all products are translated - and for these products I have to display the original text.

I modified MultilingualModel's getter to fallback to the default language so instead of doing:

# views.py
product = Product.objects.get(pk=1)
product_translated = product.get_translation('en')

# template.html
Name: {{ product_translated.name|default:product.name }}
Description: {{ product_translated.description|default:product.description }}

I can do:

# views.py
product = Product.objects.get(pk=1).activate('en')

# template.html
Name: {{ product.name }}
Description: {{ product.description }}

There are a few reasons why I think this is good:

1. More consistent with django's built in translation method (falls back to default if it's not translated)
2. Less code to write (at least for my case, but I'd think most other use cases are similar)

Obviously, this change breaks a few tests that expect non translated fields to return an empty string. But I'll update those if you plan on merging this in.

If you're worried about breaking existing projects, we can also make this behavior optional through a flag in settings.py (LINGUO_FALLBACK).

Let me know what you think!

Regards,
Selwin

[zmathew]

Thanks again for the suggestions. It's great to get feedback from people using this app. But this one is a little controversial with the other devs at my company.

I agree that it is consistent with i18n / gettext, but not sure if I agree with this behaviour. One of the reasons pointed out was that this behaviour hides the fact that you're missing a translation.

This issue is also related to the "content to be translated later" problem. Right now, if I had a "not null" translatable field, I MUST fill in ALL translations before saving or else the db will give me an error.

I'm going to think about this one, not quite sold on merging it in yet.

[selwin]

Hi Matthew,

The final decision is of course yours but let me try to convince you why I think my proposed behavior makes sense ;)

So I believe there are two issues, which I believe are slightly different:

1. Whether translations are optional. If you want to enforce all translatable fields to be translated, this is the logical layer to enforce this - as you said, if you have a non blank translatable field, the form will give you an error. And if we enforce all translations to be filled out, then we wouldn't need to worry about missing a translation. I also have other thoughts on this but that's a discussion for another day ;)
2. Whether to fallback to default language - as far as I know, most translation projects fall back to the default language so I'd think that's the more popular choice out of the two. And to me, that makes sense because:
   • Falling back to a default language does not hide the fact that you're missing a translation - because the text will appear in the wrong language so you'd know.
   • Showing untranslated text to visitors is better than not showing anything.

In my case, having a fall back is important because I'm integrating linguo to an already existing project with an existing model. When south creates non blank fields, south will ask for defaults. The only sensible values are "" (empty string) or None - so that's why having a fall back is nice.

[cristiano2lopes]

First of all thanks for the app, it is really useful.

I would propose, to address the point number 2, that we add a setting (that can be turned on for instance on a development or qa environment) that when no translation is provided returns a [MISSING TRANSLATION] string instead of falling back to indicate the missing translation.

We could also add a setting to disable the fallback so that the changes don't impact apps already in production.

I can make this change if there is real interest in pursuing this fallback approach because i would really enjoy to go back to the canonical version of the app instead of pointing to my fork.