ember-intl
ember-intl copied to clipboard
Nested folder structure doesn't seem to work on Windows
- [x] I am on the latest ember-intl version
- [x] I have searched the issues of this repo and believe that this is not a duplicate
Description
Hello. I tried to organize translations using nested folders. I can see the translations when I run the app locally on Mac, but another developer who works on Windows has been seeing "missing translation" error.
When I removed nested folder structure (i.e. have 1 file, translations/en-us.yaml
), both of us could see the translations. I wondered if there may be an OS issue with joining directory paths that ember-intl
isn't accounting for.
https://github.com/ember-intl/ember-intl/issues/159 seemed to be a similar past issue that arose due to OS differences.
Environment
- Ember Version: 3.21.3
- Ember CLI Version: 3.18.0
- Ember Intl Version: 5.5.0
- Browser(s): Chrome (on Mac), Edge (on Windows)
- Node Version: 10.22.1
Steps to Reproduce
I haven't tested this with the other developer, but believe the steps may be:
- Create a new Ember app and install
ember-intl
. - Set
wrapTranslationsWithNamespace
totrue
inconfig/ember-intl.js
. - Create a component:
ember g component parent/child
. - In the component's template, add a translation
{{t "components.parent.child.some-text"}}
. - Create the translation for
some-text
intranslations/components/parent/child/en-us.yaml
file. - Call the
<Parent::Child>
component inapp/templates/application.hbs
.
When I removed nested folder structure, I set wrapTranslationsWithNamespace
back to false
.
Let me tag @imagolive for more information on what happened on Windows.
¡Same issue here!
Anytime someone builds the app in Windows we get that problem when the flag is true. Testing by building on Windows 10 64bits and also in Github Actions' Windows machine.
Any thoughts on getting a fix for this? I see that there's two PRs #1648 #1626 that attempted a fix for this issue.
#1626 was tested but doesn't work.
#1648 does indeed solve the problem.
@asanzo Thanks for checking both pull requests. I tried to see if the test provided in #1626 would pass in #1648. Unfortunately, there may need to be additional test setup in order for path.sep
to take the mocked value of \\
.
I asked the PR author to rebase their branch so that we can at least confirm that the existing tests will pass in CI.