Allow other chars for SKU rather than only latin

Hmm... interesting problem. Currently it's restricted the same way that other machine names are... do you not have this problem for things like node type names as well?

In russian language I have changed next

return preg_match('!^[А-Яа-пр-юA-Za-z0-9_-]+$!', $sku);

and I can add russian SKU
in rusian first letter is "а" last "я", but "а-я" did not work and I divided it "а-пр-ю"

Can't we just get rid of this validation and leaves it up to store admins to take care of their SKUs?

Most likely... I suppose the only reason we don't right now is to ensure easy URLs in case the SKU is used there... i.e. limiting spaces. But I don't know why we're enforcing language through that regex. : P

I think this is definitely an internationalization issue.

For the path I think we have pathauto rules/filters, for core oness we can just URL encode it and call that done.

Maybe we could rely in transliteration module (http://drupal.org/project/transliteration) as pathauto does.

#4 I agree with

#5 There is no reason why people should use the SKU in a path to the product, they might as well use the product id, like nodes uses the node id. Ids is usually a bit easier to work with, since they have a natural order, and it's even the PK of the product table. This is what commerce does in the admin backend. We can leave it up to the shop owners to decide how they want their SKUs.

I have created a store where we used views to make a display of products with product id as argument. With some custom coding, we created pathalias'es with integrating pathauto and uptained urls with this pattern:

http://example.com/category/subcategory/[product-title]-[product-id]

We had a lot of products with the same title, which was why we added the product id to url.

Anyways, unless commerce core wants to provide a default way of displaying the products, we should just open up the SKU to contain anything. If we do provide a product display, it would be much nicer integrating with pathauto and let the shop owner be able to configure the urls of his products. In any case, we shouldn't rely on the SKU for the product URL or use transliteration to create safe URLs.

I personally think there are many good reasons to use sku as the path. Currently we are building a site that uses ISBN-13 as the sku, and the publisher would like a path of products/[isbn-13]. That being said, I think most anyone who wants to do this, is capable of building a view, panel, etc to do it.

On the other hand, I think that many people who want to enter non-latin skus, shouldn't have to modify the validation. For that reason, I support not placing machine name limitations on the sku field.

Here's a patch to get started. It simply removes the sku validation code, but keeps the unique sku code.

@mikejoconnor: in the case you outlined, products/[isbn-13] links to the product node, right? So you can setup pathauto to create the URL and make sure it's well encoded for such. I.e. passing this through Transliteration module, etc?

@recidive

Thats really my point, I can think of many reasons to do this, however I think that there are plenty of other ways to achieve this without depending on sku itself. My vote is to remove the alphanumeric validation

Curious... apparently I committed this already and never marked it "fixed." :-/