I really like the Block List property editor from the first moment I used it. The Block List property editor helps me greatly simplify the data entry process in the backoffice but a scenario was presented in which I can not find a solution.
I will give you a simple scenario in order to understand what is my problem. I have the Element Type Product Variant which has the following two properties:
Product name
Stock
I will use this Element Type in order to create a Block List for my product Document Type. The site is multilanguage and I want the Product name of the variant to be localized. This means that I have to make enable Allow vary by culture for the Element Type and for the Product name property. This does not work because product variants in the product document type is not vary by culture which means that I can only edit the Block List items only in the main language.
A solution to this problem would be to make the product variants of the product document type to vary by culture but this means that I will have to make copies of the list items for each language and the Stock property of the Element type will be different for each product variant. I want to have one value for both languages and when I update on, both of them to be updated.
So the question is how can I setup my backoffice so that I will have to define one time each list element and also be able to have localized the Product name?
You should mark the products with "allow vary by culture" and then setup the varying properties on them. This would ensure that you only need to handle the names in one place.
If you want to, you could have a property on your block, with a new name, that you could then set on the product when saving / publishing.
I would suggest the first part only, to keep it simple.
For the first part, it will not work for me because I will have to create all product variants in each language. The procedure to create them takes time but this is not my problem. My problem is that a specific product variant will have different item for each language and this will have as a result, a common property for the two items (the stock) have two different values. I want the two items (for English and Greek) to have the same value for stock and if I have to reduce the stock of the variant, the change should apply for all the product variants.
For example, I have the following Product which has English and Greek contents. If my block list is varying property then I will have to create the variant object two times, one for English and one for Greek.
Product EN
Product Variant EN
Product Name EN
Stock EN <== this
Product GR
Product Variant GR
Product Name GR
Stock GR <== and this should have the same value
The two stock (may be more depending the number of languages that we have) are properties of different list elements which causes me the problem.
The stock has to be part of the variant object because each variant has its own stock value. The problem is that if the variants are multilanguage, I will have to make stock vary by culture so that I will be able to edit it in both languages. This means that I will have to update the value for both languages when the stock changes.
Another solution could be to put stock in the variants without vary. This has a small problem which is that I can change the stock only in the main language but it also causes me problem when programmatically I try to update the value. The json that I get from the content service is null. I do not know why.
Maybe you should build it with a more simple structure, and just have variants as children on the Product nodes. Would seem to be much easier to work with.
Yes, they have the same SKU because it is the same product. The problem is just for the product name which has to be multilanguage. The description is another problem but for this I can use a generic description in the content as a separate property.
This is what I did in the beginning (separate childe node for each product variant) but I decided to change it and use the Block List property editor to limit the number of nodes and make importing products easier.
In general, I do not like the way vary by culture works in umbraco. I would prefer fields that are not multilingual in a multilingual node to be able to edit them in all languages. Now you can only edit it in the default language and it is disabled in other languages. For an experienced umbraco backoffice user it is ok but for unfamiliar umbraco people who use umbraco for data entry, it confuses them the way it works.
Block List with vary by culture properties
Hello,
I really like the Block List property editor from the first moment I used it. The Block List property editor helps me greatly simplify the data entry process in the backoffice but a scenario was presented in which I can not find a solution.
I will give you a simple scenario in order to understand what is my problem. I have the Element Type Product Variant which has the following two properties:
I will use this Element Type in order to create a Block List for my product Document Type. The site is multilanguage and I want the Product name of the variant to be localized. This means that I have to make enable Allow vary by culture for the Element Type and for the Product name property. This does not work because product variants in the product document type is not vary by culture which means that I can only edit the Block List items only in the main language.
A solution to this problem would be to make the product variants of the product document type to vary by culture but this means that I will have to make copies of the list items for each language and the Stock property of the Element type will be different for each product variant. I want to have one value for both languages and when I update on, both of them to be updated.
So the question is how can I setup my backoffice so that I will have to define one time each list element and also be able to have localized the Product name?
Thanks in advance,
Aristotelis
hi,
You should mark the products with "allow vary by culture" and then setup the varying properties on them. This would ensure that you only need to handle the names in one place.
If you want to, you could have a property on your block, with a new name, that you could then set on the product when saving / publishing.
I would suggest the first part only, to keep it simple.
HTH :)
For the first part, it will not work for me because I will have to create all product variants in each language. The procedure to create them takes time but this is not my problem. My problem is that a specific product variant will have different item for each language and this will have as a result, a common property for the two items (the stock) have two different values. I want the two items (for English and Greek) to have the same value for stock and if I have to reduce the stock of the variant, the change should apply for all the product variants.
For example, I have the following Product which has English and Greek contents. If my block list is varying property then I will have to create the variant object two times, one for English and one for Greek.
The two stock (may be more depending the number of languages that we have) are properties of different list elements which causes me the problem.
Why not:
The stock has to be part of the variant object because each variant has its own stock value. The problem is that if the variants are multilanguage, I will have to make stock vary by culture so that I will be able to edit it in both languages. This means that I will have to update the value for both languages when the stock changes.
Another solution could be to put stock in the variants without vary. This has a small problem which is that I can change the stock only in the main language but it also causes me problem when programmatically I try to update the value. The json that I get from the content service is null. I do not know why.
Does the variants also share SKU?
Maybe you should build it with a more simple structure, and just have variants as children on the Product nodes. Would seem to be much easier to work with.
Yes, they have the same SKU because it is the same product. The problem is just for the product name which has to be multilanguage. The description is another problem but for this I can use a generic description in the content as a separate property.
This is what I did in the beginning (separate childe node for each product variant) but I decided to change it and use the Block List property editor to limit the number of nodes and make importing products easier.
In general, I do not like the way vary by culture works in umbraco. I would prefer fields that are not multilingual in a multilingual node to be able to edit them in all languages. Now you can only edit it in the default language and it is disabled in other languages. For an experienced umbraco backoffice user it is ok but for unfamiliar umbraco people who use umbraco for data entry, it confuses them the way it works.
I agree it may be confusing, but the default language is the master version in this case.
You are talking about an import. Should editors be able to create / delete product? The import should create the master always.
is working on a reply...