When using a list ( or a list of components ), we’re only able to set the list itself as localizable. It would be more useful to set the list items as localizable.
Take this screenshot:
This is a list called ‘locale’, which itself is required to be localizable, which is not desired because then the key is able to be edited between locales. Instead, the only item that should be set to localizable should be the value, making it so that the list isn’t the item to be localizable but instead the individual items in the list are.
@Sebastian - I can appreciate your position that it may complicate things, I am curious as to the details around the why/how, but I’ll take your word for it.
I am using references instead at the moment, however this is an incomplete solution because that makes it so the locale list is a global list, and no longer has the 1 to 1 relationship with the schema instance it’s being used on. This means that all items are available to all schemas that use the locale reference. This is not desired, instead a better model here is to tie the list 1 to 1 with the schema.
For my needs, a reference will work, it’s just not ideal.
How I saw this working is for schema-components, not Array lists:
When setting up a schema for a component type in another schema, the component-schema can set its fields as localizable. When choosing this child schema in the parent schema, as a ‘component’ or ‘components’ type, would not have the option available to be localizable at all, and instead it would honor the child schema’s localizable configuration
I wouldn’t want to consider the JSON field in this case.
trying to describe this shows that there is confusion in the terms being used in squidex related to component vs schema
I am not sure if it is described in the docs somewhere, but every schema can be a component. A schema of type component is a schema that cannot contain content, but has basically the same structure in the code. When a schema is used as a component the localization information is actually not honored. I know that it is complicated.
I will think about how it can be improved, perhaps with special components or so. Because otherwise the internal structure would not be backwards compatible.
e.g. the current structure for a component is this:
The above example is confusing from the user perspective. It makes sense for references, because you could decide to provide localized content and have a field where you decide per language which content is actually shown. E.g. you have hotels and depending on the language you choose another teaser hotel for your web page.
But for components the “double-localization” is weird and therefore I have decided not to support it, but of course, the following example would make sense:
Thank you for the code reference, essentially what you’re saying is that ( conceptually ) when you use a schema in place of the component, that you force it to be x-flatten 'd so that the implementation matches a component’s implementation in that components do not have localization support at all.
the double localization is what’s not sitting right to me here, and I see why you choose to ignore it in this case for the child schema. if the problem is what’s described above, then I think you’re on to something when considering to separate the component(s) type and the schema(s) type so that this could be considered.
Thanks for your nice words. Perhaps I can provide you a sample with a custom editor. The big downside is of course that it does not supports everything like validation and so on, but it is a workaround that could be okay.
that sounds interesting, and makes sense, but I wouldn’t want to ask you to make anything custom for me or anything. I’d rather accept the many-to-many relationship requirement than ask for anything custom. I was just making a suggestion in hopes that it could lead to a more ‘complete’ solution.
In any case, I appreciate you talking the problem out with me, thank you.
