If someone is interested here is my full workaround currently. It has not recieved more than ~30 mins of testing from myself yet creating various pages and trying to create collisions but I hope I've managed to get rid of all the problems with it. If someone sees a problem with this code though, please post!

namespace Piab.CMS.Business.Initialization
{
    using System.Linq;

    using Castle.Core.Internal;

    using EPiServer;
    using EPiServer.Cms.Shell;
    using EPiServer.Commerce.Catalog.ContentTypes;
    using EPiServer.Core;
    using EPiServer.Framework;
    using EPiServer.Framework.Initialization;
    using EPiServer.Web;

    using JetBrains.Annotations;

    /// <summary>
    /// This module is a workaround for EPiServer CMS UrlSegment class/generator not beeing aware of the "DisplayName" property in EPiServer Commerce and EPiServer Commerce not having a language specific "Name" property.
    /// </summary>
    [InitializableModule]
    [UsedImplicitly]
    public class CommerceUrlSegmentGenerator : IInitializableModule
    {
        public void Initialize(InitializationEngine context)
        {
            DataFactory.Instance.PublishingContent += InstancePublishingContent;
        }

        static void InstancePublishingContent(object sender, ContentEventArgs e)
        {
            var commerceContent = e.Content as CatalogContentBase;
            if (commerceContent == default(CatalogContentBase) || commerceContent.IsMasterLanguageBranch())
            {
                // We only need to work with commerce items which are not in the master language.
                return;
            }

            // Now we know that we are on a non-master language version of an EPiServer commerce item

            // WTF, what is wrong with this version? It doesn't return the correct language version?
            //var masterVersion = DataFactory.Instance.Get<CatalogContentBase>(commerceContent.ContentLink, commerceContent.MasterLanguage);


            var masterVersion = DataFactory.Instance.GetLanguageBranches<CatalogContentBase>(commerceContent.ContentLink).First(b => b.Language.Equals(b.MasterLanguage)); // This looks more ugly but seems to work.
            if (!commerceContent.RouteSegment.EqualsText(masterVersion.RouteSegment))
            {
                // The route segment already differs, do nothing (either we already changed it or the user did).
                return;
            }

            var generatedRouteSegment = UrlSegment.GetUrlFriendlySegment(commerceContent.GetPropertyValue("DisplayName"));

            // Since we were not able to use UrlSegment.GetUniqueURLSegment, which would check for collisions for us, we will have to do it ourselves:
            var siblings = !ContentReference.IsNullOrEmpty(commerceContent.ParentLink) ? DataFactory.Instance.GetChildren<CatalogContentBase>(commerceContent.ParentLink, commerceContent.Language).ToArray() : new CatalogContentBase[0];
            
            var routeSegment = generatedRouteSegment;
            {
                var i = 1;
                while (siblings.Any(s => s.RouteSegment.EqualsText(routeSegment)))
                {
                    routeSegment = string.Format("{0}{1}", generatedRouteSegment, ++i);
                }
            }

            commerceContent.RouteSegment = routeSegment;
        }

        public void Uninitialize(InitializationEngine context)
        {
            DataFactory.Instance.PublishingContent -= InstancePublishingContent;
        }
    }
}

Since a picture is worth more than a thousand words, here is also a small little picture illustrating the problem.

I'm currently browsing the swedish version of the page here, viewing swedish versions of the commerce items. But the whole commerce-part of the URL is in english?
While the automatic generation of URLSegments have always been working great for us on the CMS part of the site...

Today I tried this module I wrote with the InRiver adapter and the EPiServer Commerce Manager XML import functionality. Unfortunately this does not seem to trigger the DataFactory.Instance.PublishingContent event. So my workaround here does not actually help me. It only works when a user manually publishes a new version of a page.

So I'm back to zero I guess :-(.

Is there noone else having this issue with URLs not being translated?

How do others work? You don't care about URLs being translated? Or you actually translate every single URL by hand?

It looks very weird on our website when only the CMS parts of the URLs are translated but the commerce parts are not.

I can confirm that the Uri segment generation is a bit weird when using inRiver PIM. To have full control over how it is generated, we take care of it ourselves.

If you look up PreImport in the inRiver wiki you will discover that by implementing ICatalogImportHandler, you can modify the XML before it is handled by EPI. In this method, you can generate the UriSegment based on DisplayName, using EPI's API and modify the XML document on the fly, before it is parsed by EPI.

Thanks Johan.

Even though this solution still isn't perfect it's a lot better than the workaround I had in mind to build some kind of batch or scheduled job to fix all the segments after an import.

I have now written some code in the PreImport function that will add a proper UriSegment using the DisplayName property from the XML with the standard

string EPiServer.Web.UrlSegment.GetUrlFriendlySegment(string segment)

method. I haven't written any code that checks for sibling name collisions though as I do not want to make it overly complicated and/or slow down the import/export process too much. (That code would have to both try to search for collisions in the XML and items previously published to EPiServer).

A full unpublish+published just finished now and all the URLs seem to be properly translated, finally.

I still feel that the UrlSegment class from EPiServer CMS should be made aware of the DisplayName property from commerce though. That way all of this hackish code would not be needed.

Patching this method with DisplayName awareness should fix all of this and shouldn't require all that much work either:

string EPiServer.Web.UrlSegment.GetUniqueURLSegment(IContent content)

The default implementation is to use the Name as a basis for UriSegment, which might be suitable in some scenarios, but for the majority (not to say all) of the multi-language sites I've been working on, the product names are actually translated and hence the UriSegment should follow too. It's a delicate issue, since the same logic is used for all content - not only catalog content. Making the change to using DisplayName instead of Name as basis for UriSegment might have other consequences... O_o

But this also explains the behavior when you create a new translated version of a page - it will automatically get the UriSegment of the master language, something you always manually need to change which is kind of frustrating...

Oh, and regarding duplicates - as you prolly already have noticed, this is handled automatically when the import is performed in Episerver (see GetUniqueURLSegment). For every product that is imported, it will perform a check (run the SQL profiler to see the fun stuff) for uniqueness. If it is not unique, it will simply append a counter to the end, e.g. product-1, product-2 so no need to handle this yourself.

Actually we did get some duplicates and EPiServer did not block it when importing the XML. The duplicates were imported and we ended up with some unreachable/unroutable pages because of this.

This was because we ended up with a duplicate UriSegment for a product and when searching for a specific variant that only existed under one of these products that URL became unreachable.

We are not supposed to have products with duplicate names though inside the same category, so I retrieved list with all found duplicates and sent it to our marketing department.

If you try to edit these duplicates in EPiServer it won't allow you to save without first editing the UriSegment so that it doesn't collide with something else. The logic you are talking about on GetUniqueURLSegment is there but it won't run unless the UriSegment is left empty in the XML.

In EPiServer CMS the DisplayName property does not exist, for some reason Commerce decided to make Name non-language specific and instead add a DisplayName property. This feels really confusing and illogical. I really don't see a reason for this behaviour. To me if feels like a bad artifact still remaining after EPiServer bought Mediachase and Commerce. This makes the two products not feel fully homogeneous.