https://github.com/vinissimus/next-translate/issues/237

https://github.com/vinissimus/next-translate/issues/237

@RobinSCU I did a prerelease 0.18.0-canary.2 with this change and improving a little bit the default logger! If you can test it and provide some feedback before the 0.18.0 it would be very useful 🙏. Thanks!

Closes https://github.com/vinissimus/next-translate/issues/237

CC: @giovannigiordano, @RobinSCU

It will be necessary to add the necessary documentation in the README.

There are two important changes:

• Now not only i18n.json is supported, but now i18n.js is also supported as a configuration file, so you can have functions in the configuration, as is the case with the logger.
• You can now pass logger to the configuration, as a function. If this function exists, it is executed in both development and production, and it is the responsibility of the implementer to make sure that their code is executed where is necessary. However, if logger is not passed in the configuration will run the default logger that only runs in development showing the console.warn as before.

Hi,

we have a pretty large eCommerce website and unfortunately, we have some error messages/key from external APIs we don't know and they can even change. Is there a way we can log these missing keys in production so that our translation Team can find them more easily?

When we could inject an function via i18n.js like this it would be unbelievable great :) :

missingKeyHandler: (key: string): string => { 
    // logging part
    return ''
}

Thanks Robin

From version 9.5.7 of Next.js, the Next.js Link component itself will have the same functionality as the next-translate Link.

I share the documentation on the subject:

https://github.com/vercel/next.js/pull/18067/files

This means that maybe we can deprecate the Link and Router from next-translate so that people can use the Link and Router from Next.js directly. You will only have to replace lang with locale.

It is still experimental, and we will have to make several tests before. So for the moment, I don't close this issue. But for me, it makes sense to evolve around here, since the same functionality that I implemented will now be in the Next.js core.

Closes https://github.com/vinissimus/next-translate/issues/237

CC: giovannigiordano, RobinSCU

It will be necessary to add the necessary documentation in the README.

There are two important changes:

• Now not only i18n.json is supported, but now i18n.js is also supported as a configuration file, so you can have functions in the configuration, as is the case with the logger.
• You can now pass logger to the configuration, as a function. If this function exists, it is executed in both development and production, and it is the responsibility of the implementer to make sure that their code is executed where is necessary. However, if logger is not passed in the configuration will run the default logger that only runs in development showing the console.warn as before.

https://github.com/vinissimus/next-translate/issues/237

There were some messages that the logger said incorrectly. With this, they are corrected giving better feedback, without saying undefined (in case there is no namespace).

There were some messages that the logger said incorrectly. With this, they are corrected giving better feedback, without saying undefined (in case there is no namespace).

Hello, first of all thank you for the great library. I have everything working perfectly across locales, so /en/blah and /de/blah work great. However I need to localize quite a few routes into different locales. So I want to load [lang]/blah on de/bleh, fr/bluh etc.

I tried to get this working with the experimental rewrites from Next, but every combination I try results in a 404. If I set the destination to a static route it rewrites fine so I know the rewrites themselves are working, and the source is formatted properly.

For the destination I tried:

/:lang/blah /:lang/blah?lang=:lang /[lang]/blah /[lang]/blah?lang=:lang

And various other combinations but nothing worked. Maybe I just don't follow how Next handles this internally. 🙈

I could make bleh and just import blah but that has the negative side effect of also enabling /en/bleh and just in general it's cumbersome to maintain with many routes.

I would appreciate any suggestions.

In case it matters I am using the example from here as a base (so without the build step): https://github.com/vinissimus/next-translate/tree/master/examples/with-dynamic-routes

Using the build step the lang is not a dynamic route, it's generated at build time as /es/[blog], /en/[blog], etc. Anyway, now next.js is advancing in i18n and soon there will be better support. Perhaps it would be good to move the discussion on this issue:

• https://github.com/vercel/next.js/discussions/17078

The "build step" is a workaround as long as there is no better support, but soon things will probably be simpler and in version 1.0.0 of next-translate no build-step will be needed.

So I think it's best to close this issue and address this implementation in the Next.js RFC

@sven-ra Using the build step the lang is added as prop to the getStaticProps.

I'm also interested in the solution 👏

By default, the "flash" still has the same behavior as before. But at the same time, now from the configuration you can modify the behavior.

For example, if we want to use antd's message, we could do it with:

import { message } from 'antd';

// ...

const supportedMessageType = new Set(['error', 'warning', 'success']);

const config = {
 flash: (msg, type) => {
    if (supportedMessageType.has(type)) return message[type](msg);
    message.error(msg);
  }
  ...restOfConfig,
}

// ...
return (
  <Guillotina
   client={client}
   config={config}
   url={url}
   registry={registry}
  />
)

@zeg-io thanks to report the issue 😊 I fixed and prereleased on 0.18.0-canary.1. Now it should work 👍 It will be finally released on 0.18.0 during the next weeks.

Closes https://github.com/vinissimus/next-translate/issues/277

In the case of the following translation I get the standard react key missing error.

"somekey": "this text contains <0>bold text</0> and this other text <0>is also bold</0>."

<Trans
        i18nKey={'ns:somekey'}
        components={[<b />]}
      />

However, if I do not attempt to reuse the component it works fine: "somekey": "this text contains <0>bold text</0> and this other text <1>is also bold</1>." (note the <1> tag)

<Trans
        i18nKey={'ns:somekey'}
        components={[<b />, <b />]}
      />

Closes https://github.com/vinissimus/next-translate/issues/277

I didn't do it to make the review easier

You should run npm run format:all and then do a commit with all the formatted files 😊

Before:

Now:

What was happening?

This code:

React.useEffect(() => {
    (async () => {	
      await get("@behaviors");	
    })();	
  }, []);

After microbundle it becomes to:

 React.useEffect(function () {
    try {
      return Promise.resolve(get("@behaviors")).then(function () {});
    } catch (e) {
      Promise.reject(e);
    }
  }, []);

As useEffect works in (P)React, here the cleanup is a promise... And should be a function! So when the component is unmounted can't unmount well, throwing an error. The issue can be reproduced whenever we leave the Behaviors or Permissions tab.

Changing the content of the useEffect to:

React.useEffect(() => { get("@behaviors") }, []);

It solves the problem. get("@behaviors") returns a promises, but is not necessary to indicate that the function is async because we don't need to await that promise. So now there isn't a wrong cleanup for the unmount event.

Bumps junit from 4.8.1 to 4.13.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/junit-team/junit4/releases">junit's releases</a>.</em></p> <blockquote> <h2>JUnit 4.13.1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.1.md">release notes</a> for details.</p> <h2>JUnit 4.13</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md">release notes</a> for details.</p> <h2>JUnit 4.13 RC 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 RC 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 3</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.12</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md">release notes</a> for details.</p> <h2>JUnit 4.12 Beta 3</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md">release notes</a> for details.</p> <h2>JUnit 4.12 Beta 2</h2> <p>No release notes provided.</p> <h2>JUnit 4.12 Beta 1</h2> <p>No release notes provided.</p> <h2>JUnit 4.11</h2> <p>No release notes provided.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.1.md">junit's changelog</a>.</em></p> <blockquote> <h2>Summary of changes in version 4.13.1</h2> <h1>Rules</h1> <h3>Security fix: <code>TemporaryFolder</code> now limits access to temporary folders on Java 1.7 or later</h3> <p>A local information disclosure vulnerability in <code>TemporaryFolder</code> has been fixed. See the published <a href="https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp">security advisory</a> for details.</p> <h1>Test Runners</h1> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1669">#1669</a>:](<a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1669">junit-team/junit#1669</a>) Make <code>FrameworkField</code> constructor public</h3> <p>Prior to this change, custom runners could make <code>FrameworkMethod</code> instances, but not <code>FrameworkField</code> instances. This small change allows for both now, because <code>FrameworkField</code>'s constructor has been promoted from package-private to public.</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66"><code>1b683f4</code></a> [maven-release-plugin] prepare release r4.13.1</li> <li><a href="https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2"><code>ce6ce3a</code></a> Draft 4.13.1 release notes</li> <li><a href="https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24"><code>c29dd82</code></a> Change version to 4.13.1-SNAPSHOT</li> <li><a href="https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567"><code>1d17486</code></a> Add a link to assertThrows in exception testing</li> <li><a href="https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9"><code>543905d</code></a> Use separate line for annotation in Javadoc</li> <li><a href="https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944"><code>510e906</code></a> Add sub headlines to class Javadoc</li> <li><a href="https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae"><code>610155b</code></a> Merge pull request from GHSA-269g-pwp5-87pp</li> <li><a href="https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec"><code>b6cfd1e</code></a> Explicitly wrap float parameter for consistency (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1671">#1671</a>)</li> <li><a href="https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646"><code>a5d205c</code></a> Fix GitHub link in FAQ (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1672">#1672</a>)</li> <li><a href="https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8"><code>3a5c6b4</code></a> Deprecated since jdk9 replacing constructor instance of Double and Float (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1660">#1660</a>)</li> <li>Additional commits viewable in <a href="https://github.com/junit-team/junit4/compare/r4.8.1...r4.13.1">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Yes, I hope so too!

@TheFullResolution we are currently using the "custom server" version, documented here:

• https://github.com/vinissimus/next-translate/blob/master/docs/USING_CUSTOM_SERVER.md

For the redirects, we are using an extra Node middleware that checks the location and the lang and redirects (or no) to the correct one.

Although we currently have this implementation, the Next.js team now advises against using a custom server, as you can now use their own API for redirects and middleware. I guess we will gradually migrate to this option.

Hope it helps.

I want to know how can i set dir for HTML tag in _document ? for example next-i18next provides a function called "i18n.dir" it gets a lang name to give its direction i18n.dir("en") ==> "ltr".
HTML direction for some langs like persian and arabic must be "rtl"

@saeedPadyab I close the issue, if you still have a problem, don't hesitate to reopen the issue.

@saeedPadyab you can set dir for HTML tag in _document doing:

import Document, { Html, Head, Main, NextScript } from 'next/document'
import documentLang from 'next-translate/documentLang'

const rtlLangs = new Set(['ar', 'dv', 'fa'])

export default class MyDocument extends Document {
  const lang = documentLang(this.props)
  const dir = rtlLangs.has(lang) ? 'rtl' : 'ltr'

  render() {
    return (
      <Html lang={lang} dir={dir}>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

And to ensure to work when browsing pages to another language, you can include a hook:

import { useRouter } from 'next/router'

// ...

const { pathname } = useRouter()
useEffect(() => { document.dir = rtlLangs.has(lang) ? 'rtl' : 'ltr' }, [pathname])

Hope it helps.

Adds @thanhlmm as a contributor for code.

This was requested by aralroca in this comment

@allcontributors please add @thanhlmm for code

Fix bug can not copy style file to build folder (.css, .scss files)

We no longer need to copy styles file to destination folder as Nextjs document said that we can put style file anywhere.

Impact on current build: None

@thanhlmm thank you a lot for your contribution!

I think the best option is to allow i18n.js for the configuration, because i18n.json is not possible to storage functions. This way the missingKeyLogger function can be added to the config in a simple way. We can support both, .js and .json to don't add any breaking change.

@giovannigiordano I prereleased under 0.17.3-canary.5

Add a logger for missing keys. The logger function can be overwritten by passing it as a prop to I18nProvider. Close #237

Hi,

we have a pretty large eCommerce website and unfortunately, we have some error messages/key from external APIs we don't know and they can even change. Is there a way we can log these missing keys in production so that our translation Team can find them more easily?

When we could inject an function via i18n.js like this it would be unbelievable great :) :

missingKeyHandler: (key: string): string => { 
    // logging part
    return ''
}

Thanks Robin

@shunkakinoki I prereleased the PR under 0.17.3-canary.4 if you want to try it.

I reopen the issue because although I have merged the PR because it didn't block, we still need to solve the navigation with dynamic-routing + custom server

Hi once again! Thanks for the awesome project

Since v9.5.3, it seems like the <Link> component was updated for dynamic routing, making the prop as= behave as href=

Updating the canary package to reflect this would be great!

Links: https://github.com/vercel/next.js/pull/16774 https://github.com/vercel/next.js/pull/16634

Closes https://github.com/vinissimus/next-translate/issues/250

TODO:

• [ ] Support with custom server (I don't know yet how to replace the as to redirect to the current language)

Hi once again!

Next v9.5.5 has been released today, with initial changes for i18n https://github.com/vercel/next.js/releases/tag/v9.5.5

As far as I have tested, the lang path seems to be automatically generated/handled by next.js, perhaps eradicating entirely the need for a build step? How will the library evolve to v1.0.0 given the official i18n rfc?

I'm happy to devote as much as possible to contribute to this awesome library!

@shunkakinoki I think it is better to move the discussion into this existing issue: https://github.com/vinissimus/next-translate/issues/129

Initially, when I created this library I did the build-step as a workaround while there was no better solution. Now that it seems that Next.js is focusing on improving support for i18n, I think the most sensible thing is to adapt to its way, eliminating the build-step and other possible workarounds.

I still have doubts about how to support totally static pages (yarn export) without the build-step. Although the Next.js team comments that it is a very small percentage of the people who use Next.js, I myself for example have some projects on CDNs using Next.js + next-translate + yarn export... 🤔

That said. I close the issue and we move the discussion to the already open issue to talk about the evolution of this library.