-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accept locale as configuration #7890
Comments
Yeah, I'm not sure of a way to set this exactly. Tried a few things as well and was unable to change the locale. |
The Chrome DevTools team recently added the possibility to change this via the "Sensors" tab in the DevTools. They also expose this as experimental API to the Chrome DevTools Protocol. There is: I was able to set the locale and the timezone in my tests with this snippet: it("should set the expected locale and timezone", () => {
return Cypress.automation("remote:debugger:protocol", {
command: "Emulation.setLocaleOverride",
params: {
locale: "de-AT",
},
})
.then(() => {
return Cypress.automation("remote:debugger:protocol", {
command: "Emulation.setTimezoneOverride",
params: {
timezoneId: "Pacific/Fiji",
},
});
})
.then(() => {
const { locale, timeZone } = new Intl.DateTimeFormat().resolvedOptions();
console.log(locale, timeZone); // Logs 'de-AT' and 'Pacific/Fiji'
});
}); Working example: https://github.com/jhnns/cypress-test-tiny/blob/locale-fix/cypress/integration/spec.js So this is a nice workaround. But it seems like |
Yeah, passing things to the Chrome DevTools Protocol is not officially documented. I'm going to check with the team on what our plans were for exposing/documenting this because I've seen some other people tap into it as well. Will leave this issue open for a more easily configurable way to set locale. |
Hello friends!
This solution dont work for me =/ This is my solution for the problem, enjoy! describe('Detect browser language', () => {
it('when browser language is english', () => {
cy.visit('http://localhost:3000', {
onBeforeLoad(win) { // solution is here
Object.defineProperty(win.navigator, 'languages', {
value: ['en-US'],
});
},
});
cy.contains('Welcome to react using react-i18next');
});
it('when browser language is german', () => {
cy.visit('http://localhost:3000', {
onBeforeLoad(win) { // solution is here
Object.defineProperty(win.navigator, 'languages', {
value: ['de-DE'],
});
},
});
cy.contains('Willkommen, um mit react-i18next zu reagieren');
});
}); |
Hey! // cypress/plugins/index.js
on('before:browser:launch', (browser, launchOptions) => {
if (browser.name === 'chrome') {
launchOptions.args.push('--lang=en-GB');
return launchOptions;
}
}); Note that different arguments will apply when running the tests in a browser other than Chrome. EDIT Actually the approach doesn't work when running the tests with one of Cypress Docker images. For that I had to rely in @jhnns solution based on Chrome DevTools Protocol. // cypress/support/index.js
Cypress.on('test:before:run', () => {
Cypress.automation('remote:debugger:protocol', {
command: 'Emulation.setLocaleOverride',
params: {
locale: 'en-GB'
}
});
}); |
I could not get any of the solutions to work. My application is i18n and the message displayed on the screen is different depending on the user's language (set in the browser). Unfortunately, when I run the test on my local machine and when I run it on GitHub Actions, the browser language seems to be different and I don't get consistent test results. (To make the tests pass successfully, you need to specify the messages in all languages with regular expressions). |
I think this would be really interesting as a way to test i18n or anything locale changing to work as expected. |
@syuilo at least for i18n texts we generate json files from message properties via properties-reader npm package and then use a helper function which first aggregates all json files and then returns the message string in the requested language. The code is a bit longer than 3 lines and not open source, that's why I'm not pasting it here right now. |
Any news about this issue? An additional information is that on my html the argument |
This issue is very annoying for me, because my laptop is in Plis, add a way to configure |
I have been suffering from this problem too. To use it in CI, I had to make big changes in the project, setting the language every time I needed to use cy.visit()... It got really bad. |
For us, this is also a problem, because we have keycloak as login provider and it's not easy to change the language there. |
+1! Was using Intl.DateTimeFormat which worked perfectly with |
Estou utilizando docker no gitlab e não funcionou aqui :( |
It is disappointing that after over 3 years there seems to be no option to have same test passing on github and on local. |
After I figured out that what I test is an iframe so might behave differently then the complete website I run some more tests and now I cannot get my head around: |
Any updates here? |
It got even more weird recently and we don't know what triggered it. As per MDN, it's perfectly fine to do the following to format according to the user's preferred language/locale order: const date = new Date("2012-05-24");
const formattedDate = new Intl.DateTimeFormat(navigator.languages).format(date); That now causes the following error in the page tested with Cypress.
Node 20.13.1, Cypress 13.9.0, Browser Electron 118 (headless) The reason is that It works when removing
While investigating that strange bug I concluded that I should probably set a consistent browser locale somewhere for Cypress testing. But after finding this issue it looks like that's not yet possible :/ Manually overwriting TL;DR: We need some consistency regarding locales to test properly :) |
Hi, for me, none of the above methods worked. Instead, here is what it worked:
Of course, instead of localhost you may use whatever your host name is. |
To fix this we had to create a free trial account on cypress and enable the recording of the test. That way we found out the issue was with a locale: ![image (38)](https://github.com/user-attachments/assets/db2fad23-6fec-47c0-8c6f-a93f3e4e4c4c) Probably, this works well locally because our local machines do have a default locale, but probably we don't have one when running in CI, and millify library is causing the tests to fail specifically at this line: https://github.com/Unleash/unleash/blob/363911c4a1ce94dd467a950ec84ccdc9a3ec7d75/frontend/src/component/common/AvatarGroup/AvatarGroup.tsx#L89 (validated [here](https://github.com/Unleash/unleash/pull/8040/files#diff-afc857890da2221bd34feed0ff45dd7745ff32fb0b27055214cbe69896d5311dL89)). Unfortunately, upgrading millify didn't help, but downgrading to v5 (which doesn't support locales), solve the issue at the cost of not having the up-to-date library: #8048 I believe the issue is related to this locale `c` reported here: cypress-io/cypress#7890 (comment) because only after overriding the languages this worked
First of all: thank you for your work on Cypress 🙏. It's awesome and such a pleasure to use!
Current behavior:
I have no unified, platform-independent way of controlling the browser locale. Setting it is specific to the browser and platform and thus error prone.
Desired behavior:
My goal is to get a predictable output of
new Intl.DateTimeFormat().resolvedOptions()
. I'm on macOS and I haven't found a way to set the browser locale in Chrome. It always resolves tolocale: "en-GB"
but it should resolve toen-US
. I tried setting theLANGUAGE
,LANG
,LC_ALL
environment variables but it seems like they are ignored or overwritten. I also tried the--lang
argument but that doesn't work as well (I read that it's only supported on Windows).I also tried setting
launchOptions.preferences.default["settings.language.preferred_languages"]
launchOptions.preferences.default["intl.initial_locale"]
launchOptions.preferences.localState["variations_safe_seed_locale"]
during
'before:browser:launch'
but with no luck.To be honest, I didn't even get Chrome to start from the command line with the correct locale. I tried it with this command:
LANGUAGE=en-US LANG=en-US LC_ALL=en-US ./"Google Chrome" --user-data-dir="~/temp" --lang="en"
So this is probably also kind of a Chrome issue.
I saw that Cypress is using a dedicated user profile located in
~/Library/Application Support/Cypress/cy/production/browsers/chrome-stable/interactive/Default
. Maybe it needs to be set somewhere there...In this issue I'm asking for two things:
In case you know a way how to set the Chrome locale or even in case you know that this is still an unsolved issue, could you please document this in this issue? I think this could be a common problem since a lot of web developers are on macOS.
It would be nice if Cypress offered an easy, cross-platform configuration for setting the browser locale. There is a similar request for the timezone and I think this is quite common: you want to control the locale and the timezone your tests are executed with. (Btw: setting the
TZ
env variable works fine).Test code to reproduce
Versions
The text was updated successfully, but these errors were encountered: