Trying to Dynamic update of Translate id

Do you want to request a feature or report a bug? bug

What is the current behavior? Trying to translate my route names in my breadcrumbs

Dynamic update of Translation id on translation component seams to defualt to rout name when using react router. I first thut that it jus did not update on uppdating the id and defualts to the defualt translation. But it updates and breakes translation in a wired way. I have setup and codesandbox with diffrent tests. Reactrouter links and a switch to switch between “pages”.

Links of test

Hase “same key” as route…

/test1
translateId:  links.test1.title

/test1/subtest1
translateId:  links.test1.subtest1.title

/test1/subtest2
translateId:  links.test1.subtest2.title

/test2
translateId:  links.test2.title

Dose not have the same key as route

/3test3/
translateId:  links.test3.title

The last one works fine but the other ones shows the “paths name/abit of the translation id” as a translations in both my bread crums and my meny link.

The meniy link is fine onmount untill i show it in the breadcrum translation then it changes to small case instead of upper case.

Alsow tried to remov the defualt value inside of <Translation id={...}>${defualt}</Translation> and that works fine. But i need the defualt value to handel dynamic routes.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below: https://codesandbox.io/s/qv7vonxrlq What is the expected behavior? The defualt translation value should not globaly break translations?

Which versions of react and react-localize-redux are you using? “react”: “^16.6.3”, “react-localize-redux”: “^3.5.1”,

[ryandrewjohnson]

I believe at the time of development I was contemplating whether to make the inline translation override configurable. At the time I felt that the API footprint was getting a bit verbose, and ended up opting to not make it configurable.

I agree that this could be confusing, and is something that should be added to the roadmap for next major version. As we’ll be able to reevaluate how configurable options are passed in.

[ryandrewjohnson]

Now tracking in #140