Are you using an alternate view for displaying your product (e.g. Views\Content-Product.Detail.cshtml)? In which case you can wrap the Taxonomy's Name property in T wherever the Taxonomy appears:
Disadvantage is, of course, that you will have to supply the translations in a .po and not through the CMS. Nice thing about the .po is, however, that it will fall back to the source language if a translation is not available.
Throughout Orchard - and dare I say throughout the internet - localization of hierarchical content (content items & taxonomy fields, but also blogs & blogposts) is difficult to get right. I find myself forever "compromising" between the usability
of the CMS and the usability of the site's front-end - stopping just short of creating dedicated sites for each language.
I have quite a standard setup for localized sites in that I include alternates for most fields in the theme (e.g. Views\EditorTemplates\Views\Enumeration.Edit.cshtml) so that I can wrap the labels and (e.g. select list -) values in T(). (Note to self to submit
a pull request to get this included in Orchard.Fields!)
The CultureSelector implementation that I use has some logic to fall back to the container's language if localization is not provided at the item level. So, for example, blogpost does not have the localization part attached, but a blog does. So if a visitor
changes the language whilst on a blogpost, it will display the blog (-listing) for their selected language instead.
Gone way off topic now, but hopefully some pointers to assist you in solving your problem.