I have…
- [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.
I’m submitting a…
- [x] Regression (a behavior that stopped working in a new release)
- [x] Bug report
- [ ] Performance issue
- [ ] Documentation issue or request
Current behavior
In our schema we have a localised asset. In the Squidex language settings we have defined appropriate fallbacks and they work great for text etc. However it looks like they don’t work for assets for some reasons, if the asset property isn’t defined for a given language the graph API will return an empty array for the asset, e.g. "previewImage": [].
I found this feature request, but I don’t think it reports this bug (in fact it looks like it worked for him back then, so it might actually be a regression): Localized assets
Expected behavior
Assets use language fallbacks like other properties marked as localised.
Minimal reproduction of the problem
- Define two languages, one being the master language, the other having the master language as fallback.
- Define a schema with a localisable asset.
- Create content based on that schema and add an asset for the master language, but not for the second language.
- Query the content via graphQL and set the language to be the second (non-master) language.
Environment
- [ ] Self hosted with docker
- [ ] Self hosted with IIS
- [ ] Self hosted with other version
- [x] Cloud version
Version: current cloud version, not sure where to look it up.
Browser:
- [ ] Chrome (desktop)
- [ ] Chrome (Android)
- [ ] Chrome (iOS)
- [ ] Firefox
- [ ] Safari (desktop)
- [ ] Safari (iOS)
- [ ] IE
- [ ] Edge
Others:
We are querying the data using the apollo-android graphQL library and set the language using the X-Languages header (it works fine for other property types than assets).
You could say it works on the API level but not on the UI level. The problem is: When do you want to use the fallback?
Right now the behavior is that the fallback is used when no value is defined. But for assets an empty array is a valid value. Therefore it does not resolve the fallback. It could even be on purpose if you do not need an asset for a language.
I am not sure how to solve that.
Hm, not sure I agree here.
You could also argue the same for every other property, e.g. plain text: If a text property isn’t set for a specific language that might also be intentional and in this specific use case one might also expect it to stay empty. Still right now the fallback is applied in that case (because in 99% of the cases that’s what the user would want).
From your description I understand that assets don’t have an empty value state at all if you set them (or not set them) via UI, they are always at least an empty array. So, if you wanted a real “not set” state which works across all properties (because again the use case is IMHO valid for all localised property types) that would mean that every localised property (no matter the type) would have to have a checkbox (e.g. “unset/null”) to indicate that it should really stay not set and don’t fall back to whatever is defined in the fallback language.
However, as we don’t have this behaviour for the other types right now and you likely don’t want to introduce it now for all of them, I’d suggest to keep things consistent with how it is for the majority of types and handle localised assets just like any other localisable type (meaning there is no such thing like an unset localised property if there is a fallback language which has a value defined).
I recognise that my description is lacking, but I don’t know how to explain it better. Does it make any sense?
Actually the string has had the same problem and it was fixed in an not very good way.
An asset could have three states:
- Unset / null / undefined
- Empty array (default)
- Non empty array
Very similar to strings
- Unset / null / undefined
- Empty string (default)
- Non empty string
Very similar to numbers (but not the same)
- Unset / null / undefined
- Zero (default)
- Non zero number
And the UI very often does not distinguish between default and unset values. But default value is a totally valid case where the fallback handling should not kick in. So what is missing is a button to unset a value and an indicator in the UI. Making assumptions is difficult because there are so many other cases where an empty array is intentional.
1 Like
Ah, sweet, didn’t think going all in with the unset checkbox/button solution for all types was an actual option. 
Given it’s likely a bigger task than the other option (handle assets like other localisable types), I guess there is no ETA, is it?
I can implement and deploy it next week. The main challenge is to find a good visual design for the UI. If you have a suggestion how to visualize that a value is unset and where and how to place the button, then a mockup would be very welcome.
1 Like
That’s great news! What do you think about this?
Do you generally count the master language as a fallback as well or is it kind of a special thingy? Then “Unset and ignore fallback/master” would be appropriate, although it’s kind of a mouthful…
Speaking about master language: For the master language this checkbox should have a different label: “Unset” should be fine in this case.
@Sebastian Thanks! 
Might be I’m just blind, but where exactly can I see the change in your screenshot?
The small “X” button that is enabled when the field value is already undefined.
1 Like
Ah, neat! When can we try this out?
Perhaps today or tomorrow.
1 Like
Sorry for the delay. There are a few things in the master branch which needs carefully testing.
Sure, no worries. Better safe than sorry.
Hi, I have deployed this finally.
Great news, thanks a lot! Seems to work as it should. 
1 Like
