Allow Assets Field and Entries Field to be managed at the site, site group, and language level

[codyjames]

It would cool if Assets Fields (and Entries Fields) could be managed at the site, site group, and language level in the same way as other fields. For instance, we have an "English" site group and would want to use the same assets for all of those sites, but a French site may use a different asset.

[codyjames]

We could really use this right now. We're in the process of translating a site into 12+ languages and the current options for assets really force us down some wonky/hacky paths.

[brandonkelly]

I’m not even sure how we’d go about this, as there is currently a direct correlation between assets and the physical files on the server.

One option is you could create a volume specifically for holding “translated” assets, and put a “Translated File” custom Assets field on your main asset volume, connected to the translated asset volume & set to manage relations on a per-site basis. Then use your main volume to hold the “primary” language’s assets, and whenever you need to supply a translated version of an asset, just double-click on it, and upload a file to the Translated File field.

Then from your template, do this whenever dealing with an asset:

{% set asset = asset.translatedFile.one() ?? asset %}

Or if looping through multiple assets, you could eager load them.

{% set assets = entry.myAssetsField.with(['translatedFile']).all() %}
{% for asset in assets %}
    {% set asset = asset.myAssetsField[0] ?? asset %}
    ...
{% endfor %}

[codyjames]

Oops. I think I wasn't quite clear here, I'm talking about the Assets Field.

I want to be able to set an Assets Field on an Entry and have it be set for all sites in that Site Group (or whatever translation method I choose). Same goes for Entries Field.

Ideally all fields should have the same translation method options available.

[brandonkelly]

Ah, right, sorry I must have been thinking of a different issue.

Making relations translatable with the same modes as normal fields would be quite a big change, so not something we would do unless this FR got significant traction.

[jsunsawyer]

Without this feature, translations are really confusing to explain to the client. It immediately introduces an exception to how groups work.

User wants to edit an image and text field for all sites in an English site group.

• User updates text field content: Text is updated for each site in group.
• User updates an image: Image is updated for the current site, other sites in the group use the old image.

Outside of creating extra work, this inconsistency introduces a scenario where content can easily and unintentionally get out of sync.

This seems like a really important change to make translations clear and consistent.

[mats852]

This is a feature I stand behind for sure !

[michaelhue]

@brandonkelly Would you accept a pull request for this? I'm not very familiar with the internals of the relation fields but I'd be willing to give it a shot. A little guidance would go a long way though.

Update 3.2 added propagation methods for sections and matrix fields, which is fantastic for "true" multi-site + multi-language setups. The two relation fields being an exception hurts the experience.

I completely agree with @jsunsawyer; clients are repeatedly confused by this.

[brandonkelly]

@michaelhue I think it’s best if this one is resolved in-house. We are going to be making other content modeling-related changes in Craft 4, so I think that would be the best time to try to tackle this. I’ll add it to that milestone and see what I can come up with.

[timkelty]

To clarify: you already can manage these per-site, right? ("Manage relations on a per-site basis" checkbox in field settings)

So the issue remains for how to manage them on the group level, right?

I use https://github.com/timkelty/craftcms-site-sync to get around some of these issues. Not sure if it will fit your use-case, though.

[wsydney76]

so not something we would do unless this FR got significant traction.

Happy to add some traction. A lot. The lack of this is leading to a lot of confusion/inconsistency/epic instructions/strange workarounds.

[soschubert]

Looks like this is still unsolved?

We want to offer some files for download and they are in different languages. Almost everything else is 'translatable' but not the asset content/field.

We used a workaround for now, but we'd be happy if there is a clean solution for it in the future.

[andris-sevcenko]

@soschubert there will be, but for it to be clean, there needs to be a refactor of how content modeling works in Craft. Currently looks to be slated for 5.0.

[johnwbaxter]

I found this one a bit confusing when creating a multi site site. Coming from EE land, I was expecting everything to be interchangeable so this threw me a bit :)

To get around this, I wrap fields like this in a supertable field so that it's translatable, but I do think that they should be translatable like everything else.

[maxstrebel]

Thats a clever hack @johnwbaxter.

I sincerely hope you consider a Refactor in 4.0, @andris-sevcenko. After my last Multisite Project, I'm mildly frustrated (because it is a bump in an otherwise very positive client experience). Translations and also Asset Paths on a Site basis are all big hacks right now.

[jalendport]

Gonna add a +1 to this; just ran into a usecase where the ability to translate asset fields per group would be super helpful...

Thanks for the workaround @johnwbaxter; gonna have to roll with that for now 🙌

[jacksoncool]

bump... This would be really useful especially for globals.

[cmalven]

Running into this on a current project. Each site should have it's own "logo" asset, but there is no easy way to manage this with a single asset field that is shared between sites.

[mats852]

In the meantime, for static assets, I do something like that:

<img src="/static/svg/logo_{{ craft.app.language |split('-') |first }}.svg" alt="" />

[jalendport]

@cmalven I think what you're describing is a little different from what this issue is about. I'm fairly certain you can achieve what you're describing with one asset field set to "Manage relations on a per-site basis" that you stick in a global perhaps. What we're asking for in this issue are options to "Manage relations on a per-site-group basis" and "Manage relations on a per-site-language basis".

[cmalven]

@jalendport That may be. It seemed from the initial message that kicked this off and some of the comments, that the request was that Asset fields had the same translation options as other fields. e.g. Not Translatable, Translate for Each Site Group, etc. I may be able to achieve what I'm trying to using Manage relations on a per-site basis. I didn't realize that existed until you mentioned it just now.

[brandonkelly]

@cmalven Yep that’s exactly what you need.

[animaux]

Yey! Manage relations on a per-site basis, thanks! \o/

[dr-codswallop]

Another +1 request for this.

I'm also using the workaround from @johnwbaxter for now, but would be really helpful for asset fields to have the same translation options as other fields natively. Especially in my current use case for choosing an image per site group in a global.

[oriolnoya]

Another +1 request for this.

Meanwhile, I'm using the following workaround: I wrap the asset in a "Link field" from this plugin: https://github.com/sebastian-lenz/craft-linkfield

[Antimated]

+1 on this. I need to add a logo for each site group. Each site group has 5 languages. So if the logo changes the client has to change the logo 5 times :/

[brandonkelly]

Alternatively, you could create separate Assets fields for each site group, and then set each of the fields to only show for their intended site group, via field conditions in the field layout designer.

[mark-wff]

+1 on this.

This is a requirement that we have in almost all of our projects. To achieve translation in different groups or languages, we use a Matrix-Field with a File-Field. It would be great if asset-fields could be translated as a native feature

[brandonkelly]

Relation fields are gaining full Translation Method support in Craft 5.3 (#15400) 🎉

[brandonkelly]

Craft 5.3.0-beta.1 is out with that change 🎉 (#15400)

We’re targeting August 6 for the GA release. If you’d like to test ahead of time, change your craftcms/cms requirement in composer.json to:

"craftcms/cms": "^5.3.0-beta.1",

and then run composer update.