0.19.3-canary.1

• Fix loading namespaces when it has a withTranslation hoc #301

0.19.2

Thanks to @croutonn for this mini-release 😊

PATCHES

• Fix builder problem with group exports #298 (by @croutonn)

0.19.1

PATCHES

• Fix localesPath when locales are in a yarn workspace or in an external package #295 (by @aralroca )
• Translate 404.js and _error.js page as normal pages #296 (by @aralroca)
• Add example without build step and without appWithI18n, just raw #294 (by @aralroca)
• Fix lang on SSR + log missing translations only in CSR #293 (by @aralroca)
• Fix getInitialProps regex #292 (by @aralroca)
• Add warning when using global imports #289 (by @aralroca)

0.19.1-canary.2

PATCHES

• Add example without build step and without appWithI18n, just raw #294
• Translate 404.js and _error.js page as normal pages #296
• Fix localesPath when locales are in a yarn workspace or in an external package #295

0.19.1-canary.1

PATCHES

• Fix lang on SSR + log missing translations only in CSR #293
• Fix getInitialProps regex #292
• Add warning when using global imports #289

0.19.0

Next 10 is already here, and with it, next-translate 0.19 🎉

Although it's a minor one, this release has BREAKING CHANGES. However, we've tried to implement backward compatibility to almost all changes so the migration should be easy.

If you look at the console there will be several console.warn telling you what to do. Also, below is a guide on how to migrate.

The goal of this release is to make a step towards version 1.0.0.

If you have any doubt/problem about the migration, please create an issue on GitHub and I'll try my best to answer them.

Also, if you want to leave your feedback of this release you can write me on twitter.

BREAKING CHANGES

• Add next.js i18n routing support #285 (by @aralroca)

CHANGES

• feat(builder): ignore test files in builder #283 (by @dnepro)

---

How to migrate from 0.18 to 0.19

Prerequisites

As a prerequisite, it is necessary to have version >= 10.0.0 of Next.js.

I recommend these readings before the migration:

• Next.js docs about i18n: https://nextjs.org/docs/advanced-features/i18n-routing
• README of this repo, because it's updated: https://github.com/vinissimus/next-translate/blob/0.19.0/README.md

1. Rename allLanguages and defaultLanguage

You should rename:

• allLanguages -> locales
• defaultLanguage -> defaultLocale

Although the old names are still supported, you'll end up receiving a warning because we are going to deprecate them in next releases.

2. Add the i18n routing config to next.config.js

Since i18n routing is now handled by the Next.js core, we must pass it to the next.config.js file:

const { locales, defaultLocale } = require('./i18n.json')

module.exports = {
  i18n: { locales, defaultLocale },
}

3. Use Next.js Link and Router

No need to use the next-translate Link and Router anymore. We can use the original Next.js, replacing lang with locale:

old way:

import Link from 'next-translate/Link'

export default function Example() {
  return (
    <Link href="/" lang="es">
      <a>Change language to Spanish</a>
    </Link>
  )
}

new way:

import Link from 'next/link'

export default function Example() {
  return (
    <Link href="/" locale="es">
      <a>Change language to Spanish</a>
    </Link>
  )
}

Although the old Link and Route are still supported, you'll end up receiving a warning because we are going to remove them in next releases.

4. Get the locale inside getServerSideProps, getStaticProps...

Next.js now adds the locale in the context.

Instead of:

export function getStaticProps({ lang }) {
  return {
    props: something(lang)
  }
}

do:

export function getStaticProps({ locale }) {
  return {
    props: something(locale)
  }
}

For getStaticPaths you should provide all the slugs for each locale, so you are receiving the locales:

export function getStaticPaths({ locales }) {
  // ...
}

4. Use Router.locale instead of clientSideLang

Instead of

import clientSideLang from 'next-translate/clientSideLang'
// ...
const lang = clientSideLang()

do:

import Router from 'next/router'
// ...
const lang = Router.locale

Although the old clientSideLang is still supported, you'll end up receiving a warning because we are going to remove it in next releases.

5. Remove documentLang, now is handled automatically by Next.js

Instead of:

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

export default class MyDocument extends Document {	
  render() {	
    return (	
      <Html lang={documentLang(this.props)}>	
        <Head />	
        <body>	
          <Main />	
          <NextScript />	
        </body>	
      </Html>	
    )	
  }	
}

do:

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

export default class MyDocument extends Document {	
  render() {	
    return (	
      <Html>	
        <Head />	
        <body>	
          <Main />	
          <NextScript />	
        </body>	
      </Html>	
    )	
  }	
}

(Or remove the _document.js if you don't have anything like this example)

Although the old documentLang is still supported, you'll end up receiving a warning because we are going to remove it in next releases.

6. Remove the I18nMiddleware in case to use a custom server

If instead of using the "build step" you're using the other alternative, by using i18nMiddleware and the appWithI18n wrapper, remember that now the i18nMiddleware is no longer necessary.

7. defaultLangRedirect config is no longer supported

Now if you need redirects you can:

• Add the necessary redirects directly in the Next.js configuration.

8. ignoreRoutes config is no longer supported

Because the i18n routing isn't a workaround anymore, it is now correctly handled without the need of this property. 😊

9. fixAs and fixHref are no longer supported

These helpers were initially for internal use of the library and were exposed here for a very concrete and punctual use case. As now the navigation is done by Next.js, we cannot maintain these helpers because they no longer give the same result as how it was internally handled before. Besides, the as in Next 10 is no longer necessary, now you can write directly in the href.

If you still want to use them, they are small helpers that you can integrate into your codebase. But they are no longer part of the next-translate API.

That's all ✋

0.18.0

In this release, there are two new things! 😊

1. You can use i18n.js for the configuration file, apart from i18n.json. Both are supported now. (You should use module.exports on the .js extension)

2. Now in the configuration you have one new property called logger to be able to capture the missing keys. This function is executed in both production and development. However, if you do not use this function by default the internal function logger that we have calls a console.warn only in development.

By the way, Next.js is now starting to support i18n. For version 9.5.7 of Next.js there will be the i18n routing part. This is very good news, and we'll probably start doing a little refactoring of what we have here. Things such as Link and Router may no longer make sense since exactly the same functionality will be in the Next.js core (replacing lang to locale). We'll see, for the moment it's experimental, but I think it's good to announce it.

In the future, when not only the i18n routing will be in Next.js, but also the part of loading the translations, we will most probably be able to remove the "build step".

FEATURES

• Add logger to appWithI18n #281 (by @aralroca)
• Add logger to config #280 (by @aralroca)
• Improve logger feedback messages #279 (by @aralroca)

BUGFIXES

• Fix Trans key on their children components #278 (by @aralroca)
• Ignore copy css file #273 (by @thanhlmm)

0.18.0-canary.3

• Add logger to appWithI18n #281

0.18.0-canary.2

CHANGES

• Add logger to config #280
• Improve logger feedback messages #279

0.18.0-canary.1

• Fix Trans key on their children components #278