Making File fields (name, description, etc.) translatable

[skirsdeda]

I need to have translations for File.name, File.description and for BaseImage.default_alt_text/default_caption.
I am using django-parler, which plays nice with django-polymorphic and such and is very clean and interoperable (as opposed to django-hvad for example).
My initial approach was to create a translated File model and custom image model with mentioned fields as translated fields. The problem is that django-parler is unable to redefine existing fields (due to django model metaclass limitations), so the only way is to create those fields with different names. But in that case I would have a very messy solution and I would have to fix various filer views, etc.
This is the code:

from filer.models import File
from parler.models import TranslatableModel, TranslatedFields
class TransFile(File, TranslatableModel):
    translations = TranslatedFields(
        name = models.CharField(max_length=255, default='', blank=True, verbose_name=_('name')),
        description = models.TextField(null=True, blank=True, verbose_name=_('description'))
    )

So my question is: would you consider making filer models translatable by default and pulling django-parler in as a dependency? I will do this anyway, but I don't want my solution to be fork-only. Any suggestions?

[skirsdeda]

I have this mostly implemented at skirsdeda/django-filer@9745bf6
There are still some problems with forms in Admin classes to be sorted out, but that's doable. I was also pondering if folder names should be translatable as well, but it would probably be more of a hassle than improvement.

[stefanfoulis]

I'm on the fence with this one. Translatable metadata has come up before. But I'd prefer to avoid the complexity and the performance hit that supporting multiple languages brings with it.

[yakky]

@stefanfoulis how about making the File model abstract, and ship an (optional) model with translated fields?

[skirsdeda]

@stefanfoulis with django-parler there's not so much complexity. The only semi-clumsy thing is working with Admin classes which don't know about translated fields at one point or another. Otherwise, it's just one table join for selects and you can still use ORM the same way only by changing field references from e.g. name to translations__name. So it's very transparent IMHO.
For performance it's also the same one table join

[maltebeckmann]

Any movement here? Are these Filer fields translatable now? @skirsdeda How did you solve this for yourself? Did you implement this with Parler?

[skirsdeda]

@maltebeckmann I have done this with Parler. You can fetch my repo branch and see for yourself. It's based on filer-1.0.4 but should be easy to rebase with some effort.

[maltebeckmann]

@skirsdeda Cheers!

[yakky]

I have a plan to make an "official" effort on this topic. This won't require any change to filer core. I'll need two or three weeks to be able to share a working example

[steffenmllr]

@yakky any progress on this ? I might need this in the coming weeks - how can I help?

[rocchidavide]

Any progress?

[jrief]

@yakky would you solve this using django-parler, or what do you mean with?

I have a plan to make an "official" effort on this topic.

[macolo]

In my opinion, the 'description', 'alt text' and 'caption' fields should be removed completely. They make little sense without the possibility to translate.

As a workaround, in any plugins that use for example the filer image field, a caption text field can be added alongside the filer image field.

The only use case that cannot easily be worked around is when using the filer folder field. Where can multi-language caption texts for each item inside that folder be gotten from?

[joeljv91]

any news on this?

[execut]

I have this mostly implemented at skirsdeda/django-filer@9745bf6
There are still some problems with forms in Admin classes to be sorted out, but that's doable. I was also pondering if folder names should be translatable as well, but it would probably be more of a hassle than improvement.

@skirsdeda Please tell me where can I get these changes for further revision?
Now I see this message and cannot connect to your branch=(
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

[skirsdeda]

@execut the branch is here. It is very outdated though.

[execut]

@execut the branch is here. It is very outdated though.

Thanks, I'll try to adapt to the latest version.

[jrief]

How about a different proposal:
Now that a portable JSONField is available since Django 3.1, I would prefer adding a field named something like extra, addendum, data, whatever to the FileField. This would allow us to add arbitrary data to any file or image, such as translatable names, EXIF data, longdesc (deprecated, but still supported), etc.

I'm somehow reluctant to add a third-party dependency (django-parler) from which only a few power users will benefit. In my opinion, the major part of users of django-filer don't need translatable file names.

Adding translatable strings using a JSONField becomes quite simple and doesn't require any table joins when querying. It also makes adding future attributes much simpler than overriding the File or Image model.

A few packages which may help:
https://github.com/raphaelm/django-i18nfield
https://github.com/jrief/django-entangled

We should proceed with this discussion on https://django-cmsworkspace.slack.com/archives/C01DX920K60

[execut]

Interesting proposal. I also think that adding a new dependency is not a good idea. How about make an integration application django-filer-parler and move to it all dependencies?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This will now be closed due to inactivity, but feel free to reopen it.