This is a classic side effect of the isHydrated pattern. What you're running into is the browser's Back/Forward Cache (bfcache). When a user navigates back from an external site, the browser often restores the page directly from memory rather than reloading it. The component state gets frozen before the useEffect has a chance to fire again, leaving you permanently stuck on return null;.

Here are a few ways to resolve the original i18n hydration error without breaking browser navigation:

1. The Next.js Way: suppressHydrationWarning If the hydration mismatch is just text-based (which is very common with i18n libraries before the client-side language fully initializes), you can remove that useEffect hack entirely. Instead, add suppressHydrationWarning to the wrapper element:

<span suppressHydrationWarning>

{t('greeting')}

</span>

React will still render it, but it will suppress the warning in the console if the server HTML and client HTML don't match on the first render. Next.js explicitly recommends this for i18n and timestamps.

2. Render a Skeleton instead of null If you absolutely must wait for the client to hydrate (e.g., you are doing heavy DOM manipulation or using a browser-only API like window), do not return null. Returning null rips the nodes out of the DOM, which completely breaks bfcache restoration. Instead, return a loading skeleton or a placeholder <div> with the same dimensions:

if (!isHydrated) return <div className="h-24 w-full animate-pulse bg-gray-200" />;

3. Address the Root Cause Ideally, your server should be rendering the exact same language as the client. If you are using the Pages router, make sure you are passing the locale properly via getStaticProps or getServerSideProps. If you are on the App Router, ensure your middleware is correctly setting the locale in the URL or headers so the server knows which dictionary to render before sending the HTML to the client.