Gathering detailed insights and metrics for modified-next-i18next
Gathering detailed insights and metrics for modified-next-i18next
Gathering detailed insights and metrics for modified-next-i18next
Gathering detailed insights and metrics for modified-next-i18next
npm install modified-next-i18next
Typescript
Module System
Min. Node Version
Node Version
NPM Version
36.7
Supply Chain
80.6
Quality
74.4
Maintenance
100
Vulnerability
92.3
License
JavaScript (100%)
Total Downloads
1,754
Last Day
2
Last Week
9
Last Month
62
Last Year
1,123
8 Commits
1 Watching
1 Branches
1 Contributors
Minified
Minified + Gzipped
Latest Version
3.0.0
Package Id
modified-next-i18next@3.0.0
Unpacked Size
90.07 kB
Size
16.37 kB
File Count
40
NPM Version
6.14.4
Node Version
14.0.0
Cumulative downloads
Total Downloads
Last day
0%
2
Compared to previous day
Last week
80%
9
Compared to previous week
Last month
51.2%
62
Compared to previous month
Last year
447.8%
1,123
Compared to previous year
8
35
The easiest way to translate your NextJs apps.
If you are using next-i18next in production, please consider sponsoring the package with any amount you think appropriate.
Although NextJs provides internationalised routing directly, it does not handle any management of translation content, or the actual translation functionality itself. All NextJs does is keep your locales and URLs in sync.
To complement this, next-i18next
provides the remaining functionality βΒ management of translation content, and components/hooks to translate your React components β while fully supporting SSG/SSR, multiple namespaces, codesplitting, etc.
While next-i18next
uses i18next and react-i18next under the hood, users of next-i18next
simply need to include their translation content as JSON files and don't have to worry about much else.
A live demo is available here. This demo app is the simple example - nothing more, nothing less.
Easy to set up, easy to use: setup only takes a few steps, and configuration is simple.
No other requirements: next-i18next
simplifies internationalisation for your NextJs app without extra dependencies.
Production ready: next-i18next
supports passing translations and configuration options into pages as props with SSG/SSR support.
Your next-i18next.config.js
file will provide configuration for next-i18next
.
After configuration, appWithTranslation
allows us to use the t
(translate) function in our components via hooks.
Then we add serverSideTranslation
to getStaticProps or getServerSideProps (depending on your case) in our page-level components.
Now our NextJs app is fully translatable!
1yarn add next-i18next
You need to also have react
and next
installed.
By default, next-i18next
expects your translations to be organised as such:
.
βββ public
βββ locales
βββ en
| βββ common.json
βββ de
βββ common.json
This structure can also be seen in the simple example.
If you want to structure your translations/namespaces in a custom way, you will need to pass modified localePath
and localeStructure
values into the initialisation config.
First, create a next-i18next.config.js
file in the root of your project. The syntax for the nested i18n
object comes from NextJs directly.
This tells next-i18next
what your defaultLocale
and other locales are, so that it can preload translations on the server:
next-i18next.config.js
1module.exports = { 2 i18n: { 3 defaultLocale: 'en', 4 locales: ['en', 'de'], 5 }, 6}
Now, create or modify your next.config.js
file, by passing the i18n
object into your next.config.js
file, to enable localised URL routing:
next.config.js
1const { i18n } = require('./next-i18next.config') 2 3module.exports = { 4 i18n, 5}
There are three functions that next-i18next
exports, which you will need to use to translate your project:
This is a HOC which wraps your _app
:
1import { appWithTranslation } from 'next-i18next' 2 3const MyApp = ({ Component, pageProps }) => <Component {...pageProps} /> 4 5export default appWithTranslation(MyApp)
The appWithTranslation
HOC is primarily responsible for adding a I18nextProvider
.
This is an async function that you need to include on your page-level components, via either getStaticProps
or getServerSideProps
(depending on your use case):
1import { serverSideTranslations } from 'next-i18next/serverSideTranslations' 2 3export async function getStaticProps({ locale }) { 4 return { 5 props: { 6 ...(await serverSideTranslations(locale, ['common', 'footer'])), 7 // Will be passed to the page component as props 8 } 9 } 10}
Note that serverSideTranslations
must be imported from next-i18next/serverSideTranslations
β this is a separate module that contains NodeJs-specific code.
Also, note that serverSideTranslations
is not compatible with getInitialProps
, as it only can execute in a server environment, whereas getInitialProps
is called on the client side when navigating between pages.
The serverSideTranslations
HOC is primarily responsible for passing translations and configuration options into pages, as props.
This is the hook which you'll actually use to do the translation itself. The useTranslation
hook comes from react-i18next
, but can be imported from next-i18next
directly:
1import { useTranslation } from 'next-i18next' 2 3export const Footer = () => { 4 5 const { t } = useTranslation('footer') 6 7 return ( 8 <footer> 9 <p> 10 {t('description')} 11 </p> 12 </footer> 13 ) 14}
By default, next-i18next
will send all your namespaces down to the client on each initial request. This can be an appropriate approach for smaller apps with less content, but a lot of apps will benefit from splitting namespaces based on route.
To do that, you can pass an array of required namespaces for each page into serverSideTranslations
. You can see this approach in examples/simple/pages/index.js.
Note: useTranslation
provides namespaces to the component that you use it in. However, serverSideTranslations
provides the total available namespaces to the entire React tree and belongs on the page level. Both are required.
If you need to modify more advanced configuration options, you can pass them via next-i18next.config.js
. For example:
1const path = require('path') 2 3module.exports = { 4 i18n: { 5 defaultLocale: 'en', 6 locales: ['en', 'de'], 7 }, 8 localePath: path.resolve('./my/custom/path') 9}
Some i18next
plugins (which you can pass into config.use
) are unserialisable, as they contain functions and other JavaScript primitives.
You may run into this if your use case is more advanced. You'll see NextJs throw an error like:
Error: Error serializing `._nextI18Next.userConfig.use[0].process` returned from `getStaticProps` in "/my-page".
Reason: `function` cannot be serialized as JSON. Please only return JSON serializable data types.
To fix this, you'll need to set config.serializeConfig
to false
, and manually pass your config into appWithTranslation
:
1import { appWithTranslation } from 'next-i18next' 2import nextI18NextConfig from '../next-i18next.config.js' 3 4const MyApp = ({ Component, pageProps }) => <Component {...pageProps} /> 5 6export default appWithTranslation(MyApp, nextI18NextConfig)
1import { serverSideTranslations } from 'next-i18next/serverSideTranslations' 2 3import nextI18NextConfig from '../next-i18next.config.js' 4 5export const getStaticProps = async ({ locale }) => ({ 6 props: { 7 ...await serverSideTranslations(locale, ['common', 'footer'], nextI18NextConfig), 8 } 9})
Key | Default value |
---|---|
defaultNS | 'common' |
localeExtension | 'json' |
localePath | './public/locales' |
localeStructure | '{{lng}}/{{ns}}' |
serializeConfig | true |
strictMode | true |
use (for plugins) | [] |
All other i18next options can be passed in as well.
For Docker deployment, note that if you use the Dockerfile
from Next.js docs do not forget to copy next.config.js
and next-i18next.config.js
into the Docker image.
COPY --from=builder /app/next.config.js ./next.config.js
COPY --from=builder /app/next-i18next.config.js ./next-i18next.config.js
Thanks goes to these wonderful people (emoji key):
Rob Capellini π» β οΈ | Alexander Kachkaev π’ π¬ π€ π» β οΈ | Mathias WΓΈbbe π» π€ β οΈ | Lucas Feliciano π€ π | Ryan Leung π» | Nathan Friemel π» π π‘ π€ |
This project follows the all-contributors specification. Contributions of any kind welcome!
No vulnerabilities found.
Reason
license file detected
Details
Reason
no binaries found in the repo
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 0/8 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
no SAST tool detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
project is not fuzzed
Details
Reason
48 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-12-16
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More