Skip to content
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

[Issue #3078] cleanup translation related code #3089

Merged
merged 4 commits into from
Dec 16, 2024

Conversation

doug-s-nava
Copy link
Collaborator

@doug-s-nava doug-s-nava commented Dec 3, 2024

Summary

Fixes #3078

Time to review: 30 mins

Changes proposed

Context for reviewers

When testing translation behavior, it was difficult to track down why the Spanish version of the site was not loading. In the end, it was a matter of us manually setting "en" as the locale in a number of places unnecessarily. Since getMessagesWithFallbacks handles filling any missing messages in with English, so there isn't a need to manually set
the request locale to "en".

This change updates the entire app to support dynamically set locales.

It also:

Test steps

  1. add some spanish messages for local testing. Add the following to the spanish messages file:
export const messages = {
  ErrorPages: {
    page_not_found: {
      title: "No pagina nunca",
    },
  },
  Subscribe: {
    form: {
      name: "Nombre Primero",
      lastName: "Nombre Ultimo",
    },
  },
};
  1. visit http://localhost:3000/es/subscribe
  2. VERIFY: the spanish input titles added in step one appear
  3. visit http://localhost:3000/es/subscrdfafdfibe
  4. VERIFY: the spanish heading added in step one appear

Additional information

Screenshots, GIF demos, code examples or output to help show the changes working as expected.

@@ -1,6 +1,6 @@
// @ts-check

const withNextIntl = require("next-intl/plugin")("./src/i18n/server.ts");
const withNextIntl = require("next-intl/plugin")();
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see https://next-intl-docs.vercel.app/docs/usage/configuration - using a request.ts file, config will get picked up automatically. Not sure why this was in server.ts instead

@@ -16,15 +16,15 @@ jest.mock("next-intl", () => ({

describe("Home", () => {
it("renders intro text", () => {
render(<Home />);
render(Home({ params: { locale: "en" } }));
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bit unfortunate, but seems to be the best way to deal with testing a top level page that takes params from the Next system

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was there a reason for renaming this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, you can see my note in the config file - basically next intl will automatically pick up a file called request, whereas ours was called server and we had to pass a path to it to get it to work. Simplifies things slightly and makes use of built in behavior

@@ -54,12 +51,7 @@ export default function Subscribe() {
})}
</Grid>
<Grid tabletLg={{ col: 6 }}>
<NextIntlClientProvider
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

had to make this change to get tests to work, but this wasn't doing anything anyway

@doug-s-nava doug-s-nava changed the title some cleanup of translation stuff for review [Issue #3078] cleanup translation related code Dec 12, 2024
export default getRequestConfig(async ({ requestLocale }) => {
let locale = (await requestLocale) || "";

const isValidLocale = locales.includes(locale); // https://github.com/microsoft/TypeScript/issues/26255
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved this over from the getMessagesWithFallbacks code. Not a necessary change but just made more sense to me to do the locale default logic as high up in the call stack as possible

@doug-s-nava doug-s-nava force-pushed the dschrashun/3078-grab-locale-from-path branch from 32f13f3 to b10c912 Compare December 12, 2024 15:41
@doug-s-nava doug-s-nava marked this pull request as ready for review December 12, 2024 15:41
@doug-s-nava doug-s-nava self-assigned this Dec 12, 2024
Copy link
Collaborator

@acouch acouch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 🇪🇸 🚀 !

@doug-s-nava doug-s-nava merged commit 02d99c0 into main Dec 16, 2024
8 checks passed
@doug-s-nava doug-s-nava deleted the dschrashun/3078-grab-locale-from-path branch December 16, 2024 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

Translation middleware is not grabbing es value from paths
2 participants