hozana / next-translate-routes

Flexible and translated routes for Next.js without custom server
MIT License
114 stars 31 forks source link

Route using translated locale/.json file #49

Open StephaneBischoff opened 1 year ago

StephaneBischoff commented 1 year ago

Hi,

Looks like the next-translate-routes affects the next-i18n translation file logic. The 18n file (namespace) that is requested is translated.

Example folder structure:

\public
    ....
     \locales
          en\
               about.json
               ...
          fr\ 
              about.json
              ...

For some reason, locally everything works fine for both language. The correct about.json file is fetched. But once deployed to Vercel, the .json file that is request is not about.json but notre-histoire.json ?

In the browser, I see the file being fetched as https://..../_next/data/UhEhAsJqgcuNptbGTt7v2/fr/notre-histoire.json When it should be https://..../_next/data/UhEhAsJqgcuNptbGTt7v2/fr/about.json

image Looks like a redirect made by next-translate-route? I would prefer not having to change the file names (i18n namespaces)

cvolant commented 1 year ago

https://..../_next/data/UhEhAsJqgcuNptbGTt7v2/fr/about.json is not a namespace file but a static props file. I had this problem too some time ago, but I thought it was fixed... What version of next-translate-routes do you use? The last, 1.9.0? If not, can you try with it? Can you post here the code you use to link towards the about page?

simonhenke commented 1 year ago

I have a similar issue (using 1.9.1), where static props files seem to be translated although they shouldn't:

image

This HEAD-request is always sent after clicking a link. Btw, I'm also wondering why the URL of the prefetched static props (the 1st request on the image) has added the categorySlug query parameter of the catch-all-route. If the requested file exists, the catch-all page shouldn't even be relevant to next, should it?

Mabye these issues are also related to https://github.com/hozana/next-translate-routes/issues/54

vbrzezina commented 1 year ago

Hello, I have the same issue, although from some reason it's only happening in production (Vercel) if I run it localy with next dev it works fine

simonhenke commented 1 year ago

@starkys-brzezina Same here, I think that is expected. If I understand it correctly, next tries to access the cached files for the static props under _next/... On Dev, caching is turned off though.

vbrzezina commented 1 year ago

@cvolant would you be able to help or point me closer where to look for the issue? 🙏

cvolant commented 1 year ago

I will try to have a look at it but I am not sure when I will be able to (new born baby + lot of work...). Can you provide a minimal reproduction?

vbrzezina commented 1 year ago

I understand, it's not a blocker, just a little inconvinience... And congratulations by the way 🙂 Back to the point, I have following config

{ "privacy-policy": { "cs": "ochrana-osobnich-udaju", "en": "privacy-policy" }, "terms-of-use": { "cs": "podminky-pouziti", "en": "terms-of-use" }, "career": { "cs": "kariera", "en": "career" } }

when I'm in cs locale (the customized one or the one that differs from file name) and go from index page to for example /podminky-pouziti by clicking a link the resources should still be loaded as an original filename.json but it tries to load it with the translated name also resulting in one extra. 404 request.. It's only happening in production build, works fine in development

Screenshot 2023-01-24 at 17 06 09

it goes like GET 200 https://dev-extreme.com/_next/data/epE7CxH5axXvKykM_WR-p/cs/terms-of-use.json GET 304 https://dev-extreme.com/_next/data/epE7CxH5axXvKykM_WR-p/cs/terms-of-use.json HEAD 404 https://dev-extreme.com/_next/data/epE7CxH5axXvKykM_WR-p/cs/podminky-pouziti.json

cvolant commented 1 year ago

I tried to give a look at it but I don't reproduce this issue. Can provide a minimal reproduction or a reproduction using next-translate-routes /example?

simonhenke commented 1 year ago

@cvolant I spent half the day trying to create a reproduction repo, unfortunately without success 🫤 I incrementally took piece by piece from the original project (custom link component, preact, i18 libraries, several configs, next auth, ...), but nothing brought back the HEAD 404 behavior. Quite a riddle 🤔

@vbrzezina @StephaneBischoff Could you maybe try to get a reproduction of this issue? Or maybe you spot any overlaps in our dependencies that might be causing the issue?:

  "dependencies": {
    "@headlessui/react": "^1.7.7",
    "@hubspot/api-client": "^8.0.0",
    "@microsoft/applicationinsights-web": "^2.8.9",
    "@react-hookz/web": "^19.2.0",
    "@stripe/react-stripe-js": "^1.16.4",
    "@stripe/stripe-js": "^1.46.0",
    "@xstate/react": "^3.0.1",
    "applicationinsights": "^2.3.6",
    "envalid": "^7.2.1",
    "focus-trap-react": "^8.8.2",
    "form-data": "^4.0.0",
    "friendly-challenge": "^0.9.8",
    "hoist-non-react-statics": "^3.3.2",
    "i18next": "^22.0.6",
    "modern-normalize": "^1.0.0",
    "next": "^12.3.4",
    "next-auth": "^4.16.4",
    "next-i18next": "^13.0.0",
    "next-plugin-preact": "^3.0.7",
    "next-translate-routes": "1.9.1",
    "openid-client": "^5.3.0",
    "preact": "^10.11.3",
    "preact-render-to-string": "^5.2.6",
    "react": "npm:@preact/compat@^17.1.2",
    "react-cropper": "^2.1.8",
    "react-dom": "npm:@preact/compat@^17.1.2",
    "react-hook-form": "^7.3.4",
    "react-hot-toast": "^2.4.0",
    "react-i18next": "^12.0.0",
    "react-icons": "^4.1.0",
    "react-paginate": "^8.1.4",
    "react-slick": "^0.28.1",
    "react-ssr-prepass": "npm:preact-ssr-prepass@^1.2.0",
    "rehype-sanitize": "^5.0.0",
    "rehype-stringify": "^9.0.2",
    "remark": "^14.0.1",
    "remark-rehype": "^10.1.0",
    "remark-slug": "^7.0.0",
    "sharp": "^0.31.2",
    "slick-carousel": "^1.8.1",
    "unified": "^10.1.0",
    "url-parse": "^1.4.7",
    "xstate": "^4.34.0"
  },
cvolant commented 1 year ago

Thank you for the attempt. Maybe the other way around? Starting from the code that has the bug, then removing some pieces?

ahmettahasakar commented 1 year ago

I have the same problem.

I am using a custom created mapping like this.

image

This means anything that starts with a matching url is redirected. For example,

/en/about-us.json will work. But /en/hakkimizda.json will be redirected. If I disable this plugin /en/hakkimizda.json also returns the correct response. The default behaviour of nextjs is to request it as /en/hakkimizda.json in the background.

I believe most of these problems can be fixed if there is a way to make the plugin ignore ".json" urls. If one of the main goal of this plugin is to improve SEO and user usability. .json files should be irrelevant.

ahmettahasakar commented 1 year ago

I found another way. if you filter out the redirect if the following header exists, then probably it will sort itself out

image
cvolant commented 1 year ago

It is hard to debug as I don't reproduce the issue...

Can at least someone post here, it the issue persists with the last version:

But again, the best would be a public Github repo with a (minimal if possible) reproduction.

ahmettahasakar commented 1 year ago

Hello,

Yes the issue persists with the latest version.

Here is an example of a direct. there is a redirect rule in NTRConfig such as:

{ en: '/about-us', tr: '/hakkimizda' }

so if a user wants to access http://example.com/en/hakkimizda it would redirect to http://example.com/en/about-us

next js sends some prefetch ajax as in the screenshot, the server redirects /en/hakkimizda.json to /en/about-us. However, this should not redirect as it is a json request for background nextjs business. This redirect happens because of the plugin. For normal user requests everything works as it should.

image

image

cvolant commented 1 year ago

I think I reproduced this bug while trying to reproduce another one. Without using next-translate-routes. I have this redirect:

async redirects() {
    return [
      {
        source: '/fr/about',
        destination: '/fr/a-propos',
        locale: false,
      },
    ]
  },

And my prefetch (/_next/data/weodsfds_someid_dfslfjds/fr/about.json) is redirected toward /fr/a-propos.

I seems to be a bug in Next.js. Or could it possibly be a desired behavior?

Anyway, for now I think we can use @ahmettahasakar approach, but using 'x-nextjs-data' instead of 'purpose' because 'purpose' does not appear in dev.

simonhenke commented 1 year ago

@cvolant I'm still getting the 404 HEAD request even after updating to the lastest version 🫤

Here are the response headers:

HTTP/1.1 404 Not Found
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: frame-ancestors 'none'
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Feature-Policy: autoplay 'self'; camera 'self'; geolocation 'self'; payment 'self'; picture-in-picture 'self'; web-share 'self'
Permissions-Policy: autoplay=(self), camera=(self), geolocation=(self), payment=(self), picture-in-picture=(self), web-share=(self)
Referrer-Policy: origin-when-cross-origin
X-DNS-Prefetch-Control: on
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
x-nextjs-matched-path: /de/[...categorySlug]
x-nextjs-cache: MISS
Cache-Control: s-maxage=60, stale-while-revalidate
Date: Fri, 09 Jun 2023 11:45:04 GMT
Connection: keep-alive
Keep-Alive: timeout=5

and the request headers:

HEAD /_next/data/lbHZhxGd4ytwM-0WbAzFE/de/impressum.json HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Cookie: ...
Host: localhost:3000
Pragma: no-cache
Referer: http://localhost:3000
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
sec-ch-ua: "Not.A/Brand";v="8", "Chromium";v="114", "Google Chrome";v="114"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
x-nextjs-data: 1
cvolant commented 7 months ago

Hi @simonhenke, could you try with next-translate-routes@1.11.0-0?

simonhenke commented 7 months ago

@cvolant just tried the prerelease. Similar to https://github.com/hozana/next-translate-routes/pull/84#issuecomment-1836522353 I get the following error (next-translate-routes@1.11.0-3):

Collecting page data ..ReferenceError: ROUTER_CONTEXT_PATH is not defined
    at Object.<anonymous> (C:\...\node_modules\next-translate-routes\react\withTranslateRoutes.js:43:29)

On next-translate-routes@1.11.0-0-next-translate-routes@1.11.0-2 I get:

error - ./node_modules/next-translate-routes/react/withTranslateRoutes.js:38:0
Module not found: Can't resolve 'next-router-context'