Remove "v3" naming (product page) from the code base

[filipefurtad0]

What we should change and why (this is tech debt)

A products_v3 naming has been introduced in the codebase, to distinguish the new products page from the legacy version, during the time period both versions existed in the code. The legacy version and feature toggle have been removed in the meantime, but we still have references to v3 which are not necessary anymore. We should remove these.

For example,
products_v3 should be renamed to products.

Note that there are translation keys named products_v3. A plan for renaming these needs to be discussed.

Context

While looking at the codebase.

• See also Remove "v3" naming (admin styles) from the code base #13569

Impact and timeline

Improves clarity and code readability 🧹

[filipefurtad0]

As per delivery circle, we'd need @openfoodfoundation/developers feedback on whether this would be a good first issue 🙏

[chahmedejaz]

I think yes, it could be a good first issue

[dacook]

Thanks for raising this. I think this could be a good first issue, but only once we specify how to handle the translations. There are currently 82 lines here:
https://github.com/openfoodfoundation/openfoodnetwork/blob/master/config/locales/en.yml#L948

Most views are using relative "lazy lookup" keys (for example _filters.html.haml: t('.search_products') automatically maps to en.yaml: products_v3: filters: search_products). This means when the views folder is renamed from products_v3 to products, it will automatically look for translations under products. Therefore we should rename it in en.yml to match.

But this could invalidate all existing translations for products. Normally we should never update the other locale files, but to avoid messing up existing translations I think it would be appropriate to do the rename in all locale files too. It would be important to complete this within a week to avoid conflicting with other translation updates.
But I'm not 100% sure. @mkllnk do you think that would be a good idea?

[dacook]

I've also raised a separate issue for the admin_v3 styles, which I believe can be handled separately: #13569