SomewhereWarm

Hey @cqrmskwoss,

Thanks for getting in touch!

Doesn’t sound like an issue that’s in any way related to this plugin. If it’s about the WooCommerce Product Bundles extension, then please open a ticket from your WooCommerce account dashboard at https://woocommerce.com/my-account/marketplace-ticket-form/ and we’ll be more than happy to help.

Cheers,
Manos

Hey @buyhigh — can’t replicate this one. Sounds like a plugin/theme conflict?

Please:

1. Temporarily switch back to a default WordPress theme (or Storefront). If this resolves the issue, then please bring this to the attention of your theme author.
2. If the issue persists, then disable all other plugins except for WooCommerce and PD. If this fixes the issue, then slowly re-enable plugins until you find the one that triggers it.

If you are experiencing the same issue on a fresh WP install, or you are otherwise convinced this is a real issue with the plugin, please open an issue in the GitHub issue tracker at https://github.com/somewherewarm/woocommerce-product-dependencies/

Cheers,
Manos

Hey @zhukdl

Thanks for the follow up ??

Cheers,
Manos

Hey @zhukdl

It’s a cool idea — we’ve logged it internally but have no plans at the moment to expand the functionality offered by the Product Dependencies plugin.

Cheers,
Manos

Hey @bernsteinimb

Thanks for reaching out and apologies for the delay!

There’s no easy way to bulk-edit dependencies. Everything is possible, with ample resources. As this is a 100% free plugin with no business component to support its development, we have to be very careful with the features we decide to build into it to ensure we’ll be able to maintain it and keep it up-to-date in the foreseeable future.

For now there’s no plan to build any sort of bulk-editing functionality into the plugin, but if you decide to build it yourself and want to make the solution public we’d be happy to add a reference to it.

Cheers,
Manos

Hey @ryanbednar — That’s because you have probably enabled AJAX add-to-cart in catalog pages: There’s no easy way to validate this add-to-cart action and return a message there. Customers will still see a notice in the cart, though — so checking out is still not possible.

One way around this would be to disable AJAX add-to-cart for these specific products, but for some dependency types this would be possible only if the customer is logged in. Additionally, doing this for all products in an archive view could have performance implications in some cases.

This is one of those cases where deciding upon the right “default behavior” is not easy. While we have no plans to change this behavior soon, you are welcome to discuss this under the GitHub repo of the plugin and maybe submit a proposed solution/PR if you end up working with a developer to build this for you.

Cheers,
Manos

Hey @adamjohn9887

I believe this is what you are looking for: https://docs.woocommerce.com/document/composite-products/composite-products-tips-tricks-and-snippets/#thumbnail_columns

Cheers,
Manos
SomewhereWarm

Hey @adrianwackernah

Both Product Bundles and Composite Products include a Form Location option under Product Data > Advanced that allows you to stack the add-to-cart form under the single-product summary.

Product Bundles doesn’t include a “grid-style” layout yet. ?If you’d like, you could add this to our Ideas board at https://ideas.woocommerce.com – this is a great way to make feedback like this count, as the features/suggestions posted there can be upvoted by other users and prioritized based on demand.

Hey @hristo-sg

We’ve been working on a new release that adds a dedicated Customizer section under WooCommerce > Product Details. You can find it at https://github.com/somewherewarm/woocommerce-full-width-add-to-cart — feel free to send feedback once you’ve had a chance to test it, and of course report any issues you might find!

Cheers,
Manos

Hey @paaljoachim —

See https://www.ads-software.com/support/topic/feedback-68/

Thanks!

Cheers,
Manos

Hey @nitrozik — thanks for the issue report!

Could you please file this @ our GitHub repository — https://github.com/somewherewarm/woocommerce-product-dependencies ?

Thanks!

Cheers,
Manos

Duplicate – closing.

Hey @awilmsmeier

Thanks for the awesome work here!

For now I’d say we are not interested in adding more features with a potentially high maintenance overhead. This is a completely free plugin without a business side to it, so we must keep it lean in order to be able to keep it up-to-date.

I’m closing this for now, but feel free to open an issue on GitHub. We could label that as a feature request and see if it generates any traction over the next few months.

Cheers,
Manos

Hey @tobifjellner,

Yup, good examples ?? When faced with the need to construct a complex string that requires 100s lines of code to generate, it’s very likely that a developer will not have the knowledge or capacity to do it right.

In our case — some of the validation messages generated by Product Dependencies v1.3 may not be translatable in every language due to concatenation. However, the plugin allows store owners to define their own custom messages: These override the message generated by the plugin and could potentially be a valid workaround.

At the moment we don’t have the capacity to circle back here and rewrite this in a more translation-proof manner, but we’ll definitely try to learn more on the subject and apply your suggestions when the time comes to return to this code.

If anyone else is reading this — feel free to suggest code improvements that could have a positive contribution at https://github.com/somewherewarm/woocommerce-product-dependencies

Thanks @tobifjellner ?? Closing this for now!

Hey @tobifjellner

Thanks for the detailed explanation!

Seeing that _n provides multiple translation fields to account for multiple plural forms, it still seems to me that a translator can decide (depending on context) whether the English-equivalent singular should (or should not) be used in other plural forms or not.

From what I can tell the main issue of using _n in this context arises in languages like Japanese, where the translator only gets 1 field, when 2 would be required.

If so, then it might be a good idea to revise the documentation supporting _n: “Used when you want to use the appropriate form of a string based on whether a number is singular or plural.”

This description far from conveys the depth of information you are sharing here. Remember that a sentence can contain multiple singular/plural forms for nouns / pronouns, and a language that uses the same form for nouns may potentially use different forms for pronouns, e.g.:

“I bought 1 apple. It is one of the sweetest tasting apples I’ve had”.
“I bought X apples. They are some of the sweetest tasting apples I’ve had.”

In this case the first sentence might be a good candidate for _n, but not the second one? Which means that putting them together in one _n string would be bad practice.

Assuming that the two sentences need to be fed into different gettext functions, then developers will need to concatenate them as well ??

To account for RTL languages, the concatenation would need to happen via a gettext replacement — which is the only valid way to concatenate strings IMO.

Which brings me to your second point — concatenation. Is there another valid way to put together two sentences than to replace one in the other, or to use an in-between string such as %1$s%2$s, 'some context' to handle the replacement in an RTL-safe manner? As long as you concatenate full sentences this should be a reasonably safe practice.

Generally speaking, as much as we all try to follow good practices when writing code, in some cases it is very difficult to follow translation guidelines to the letter, because:

1) Developers apparently must have a basic understanding of grammar and syntax in multiple languages.
2) Very often it is impossible to structure code in a translation-aware way that accounts for every possible language.

As an example — if your objective as a developer is to display a message containing some string replacements, and these strings are dependent on the state of multiple variables, then you can either choose to concatenate once, or construct your message in a dedicated block of code by writing potentially dozens/hundreds of different versions of the same string depending on your input variables.

For most developers, the intuitively “better” approach would be to break things up and concatenate once — not out of laziness, but because there’s no other feasible way.

The extent to which a project should adhere to translation guidelines is a product-related decision with serious implications from a development/cost perspective and as such, it needs to be weighed on a cost/benefit scale.

For open-source plugins specifically, it is always up to the community itself to take initiative in implementing code changes to make popular plugins easier to translate — and as a result more accessible.

• This reply was modified 7 years, 1 month ago by SomewhereWarm.