Router translation support

[zewa666]

@bryanrsmith talked to you on private gitter about the help for this issue. We need to figure out the best approach to make existing routes translatable. So far my idea was to create duplicates of existing routes but that would create some issues with custom elements like the nav-bar, where you'd have additional logic to check when to show what version of the route.

So there might be a better approach to this. Potentially something along a custom navigation provider, which would check additional properties of the route.

Here are the community feature requests (from the Wiki https://github.com/aurelia/framework/wiki/Ideas-for-an-i18n-module):

• Route generation (prefix all routes with the language except routes for the default language)
• Route localization (http://aurelia.io/#welcome vs http://aurelia.io/#bienvenue vs http://aurelia.io/#dobro-pozhalovat)

Additionally I'm not sure how much of that should be part of the router itself and what belongs to the plugin. So I've added you as collaborator in case you need to try out things and modify stuff.

[bryanrsmith]

Cool! I'll give it some thought and try to take a closer look soon. I think it'd be good to try to keep as much of this out of the router as possible, and instead try to make it more flexible and extensible to allow the plugin to provide the customized behavior.

Couple random thoughts...

• We could add support for an optional segment in the route pattern. Eg, 'lang?/users/:id' to make the language segment optional, matching both "es/users/123" and "users/123". We'd probably still need some hook to let the plugin read the mapped route parameters.
• Maybe we could add support for route constraints that could let the plugin dynamically choose valid routes. { route: 'welcome', constraint: (fragment, params => currentLang == 'en') }. There are other issues with duplicate routes, though...
• Routes have to be named in order for generation to work, and we need a stable name that maps to all localized versions of the route that can be referenced in code. That probably means the router needs to support more complicated route configurations.
• If the changes would complicate the router too much, we could have the plugin subclass it and provide a GlobalizedRouter.
• Need to make sure we properly support unicode in route segments.

[zewa666]

@bryanrsmith you had any chance to look at this?

[bryanrsmith]

Unfortunately not. I had just started to look at implementing optional route parameters, but haven't written any code yet. There has been a steady stream of fairly important router issues that have been occupying all my time. At this point I'm not sure when I'll be able to get to it-- it'll probably take me a few weeks to get through the current high-priority router cases.