Disable translation of files section

Is there a way to disable translation of a (files) section?

It is possible for a field, but apparently not for (files) sections. I think it would be useful—if you use the files section e. g. for a gallery, it makes sense to stop users from sorting, deleting and uploading new images in another language.

Thank you!

You can use a little trick to prevent sorting, if you use a hidden sort field in your file template and set that to translate: false.

    type: hidden
    translate: false

While this will still not prevent sorting in the non-default language (i.e. the user can still move the images around), but this will not have any effect and the files are sorted again as in the default language on page reload. Some section help text could inform the user about this behavior.

As regards uploading or deleting, it doesn’t really really matter if the user does that in the default or non-default language, does it? If you think it matters, please let me know why.

As regards uploading or deleting, it doesn’t really really matter if the user does that in the default or non-default language, does it?

Yes, of course not, I thought it was possible to have a different set of files / images in different languages.

Thank you for pointing it out and also the workaround with the custom sort field!

I have an argument about this old, but I believe still relevant topic.

Correct me if I am wrong, but a files field CAN be translated, but a files section CANNOT (as stated by the OP).

Also a files field CAN allow to UPLOAD files, and so can a files section.

This may create confusion for users, in those cases where both fields have a similar function (true story).

I am having a hard time explaining this user that one of such places can be used in any language, but not the other one, when they look very similar to them (places to upload images) :woman_shrugging:

I may add that in this particular case, the section is used at ‘site.yml’ level, as an image repository, while the field is used at ‘works/work.yml’ level, to select images FROM that image repository, as asked by the user.

So both have different functions, section is a repo, field is a selector, but since the field allows to upload (to the repo), and both look very similar, the user gets confused.


Yes, if you really want to.

A files field can have upload functionality, yes. While the whole purpose of a files section is to upload files.


Yep, might be, but I wonder if this is really relevant for a Panel user.

I.e. where I give upload functionality to a files field, I probably don’t need a files section at the same time.

Fields/sections can have help text, this usually helps users not to get confused.

I wonder if it would help to change the text to Upload for the section and Select for the field, instead of Add for both.

Yes I see your point. But in this particular case both are used. One as central repo, the other one in each ‘work’ as a selector of images that come from that central repo. May not be a common case.

I could disable uploads for the fields, but it is useful for them.

I talked to the user about this, see what they say.

Well, when upload is true for the field, clicking on ‘add’ opens a ‘select | upload’ menu. May be redundant to have ‘select’ both as main button AND submenu item?

True, but then we could leave the field as is and just change the section to upload, maybe. Was just an idea.

1 Like

If you want to upvote: Files section: Rename "Add" to "Upoad" to better differentiate from files field · Kirby Feedback