next translate
2.6.2
Einfach i18n für next.js +10
Nächstes Plugin + i18n API
Notiz
Wir arbeiten mit Version 3.0.0 von Next-Translate zusammen. In den letzten Monaten haben wir uns sehr auf Brisa konzentriert. Seit der letzten Veröffentlichung ist es lange her, aber wir haben die nächste Translate nicht vergessen. Wir arbeiten an einer neuen Version, die viele Verbesserungen und neue Funktionen bringt. Wir freuen uns sehr, es mit Ihnen allen zu teilen.
Das Hauptziel dieser Bibliothek ist es, die Übersetzungen in einer nächsten.js -Umgebung so einfach wie möglich zu halten.
Next-Translate hat zwei Teile: Next.js Plugin + i18n API .
Merkmale
In der Konfigurationsdatei geben Sie jede Seite an, die Namespaces benötigt:
i18n.json
{
"pages" : {
"*" : [ "common" ] ,
"/" : [ "home" ] ,
"/cart" : [ "cart" ] ,
"/content/[slug]" : [ "content" ] ,
"rgx:^/account" : [ "account" ]
}
// rest of config here...
}Lesen Sie hier, wie Sie die Namespaces JSON -Dateien hinzufügen.
Nächstes Translate stellt sicher, dass jede Seite nur ihren Namespaces mit der aktuellen Sprache hat. Wenn wir also 100 Orte haben, werden nur 1 geladen.
Um dies zu tun, verwenden wir einen Webpack -Loader , der die erforderlichen Übersetzungsdateien in den nächsten.js -Methoden lädt ( getStaticProps , GetServersideProps oder GetInitialProps ). Wenn Sie eine dieser Methoden bereits auf Ihrer Seite haben, verwendet der WebPack Loader Ihre eigene Methode, aber die Standardeinstellungen sind:
getStaticProps . Dies ist die Standardmethode, die auf den meisten Seiten verwendet wird , es sei denn, es handelt sich um eine Seite, die in den nächsten beiden Punkten angegeben ist. Dies gilt für die Leistung, daher werden die Berechnungen in der Bauzeit statt in Anfragezeit erfolgen.getServerSideProps . Dies ist die Standardmethode für dynamische Seiten wie [slug].js oder [...catchall].js . Dies liegt daran, dass für diese Seiten die getStaticPaths definiert werden müssen, und es gibt keine Kenntnis darüber, wie die Schnecken für jedes Gebietsschema sein sollten. Ebenso, wie ist es standardmäßig, nur dass Sie die GetStaticPaths schreiben, dann wird bereits die GetStaticProps verwendet, um die Übersetzungen zu laden.getInitialProps . Dies ist die Standardmethode für diese Seiten, die einen hoc verwenden . Dies dient dazu, Konflikte zu vermeiden, da hoc eine getInitialProps überschreiben könnte. Dieser ganze Prozess ist transparent , sodass Sie auf Ihren Seiten den useTranslation -Haken direkt konsumieren können, um die Namespaces zu verwenden, und Sie müssen nichts anderes tun.
Wenn Sie aus irgendeinem Grund eine getInitialProps in Ihrer _app.js -Datei verwenden, werden die Übersetzungen nur in Ihre getInitialProps von _app.js geladen. Wir empfehlen dies aus Optimierungsgründen, dass Sie diesen Ansatz nicht verwenden, es sei denn, dies ist absolut erforderlich.
yarn add next-translate Das next-translate-plugin ist ein Tool, mit dem Entwickler Übersetzungen während des Erstellungsprozesses auf Seite zu Seite effizient verarbeiten können. Es unterscheidet sich vom next-translate , mit dem Entwickler auf die Übersetzungen in dem Code zugreifen können, in dem es benötigt wird. Das Plugin funktioniert, indem alle Seiten analysiert, nach Übersetzungen gesucht und die Datendatei umgeschrieben werden, die die Übersetzungen hinzuzufügen. Dadurch wird das Plugin zu einer effizienteren und flexibleren Lösung zum Umgang mit Übersetzungen innerhalb einer nächsten.js -Anwendung. Es wird empfohlen, das Plugin als DevDependency zu installieren.
yarn add next-translate-plugin -DIn Ihrer nächsten.config.js -Datei:
const nextTranslate = require ( 'next-translate-plugin' )
module . exports = nextTranslate ( ) Oder wenn Sie bereits als Next.config.js -Datei haben und die Änderungen darin beibehalten möchten, übergeben Sie das Konfigurationsobjekt an das nextTranslate() . Zum Beispiel für WebPack können Sie es so machen:
const nextTranslate = require ( 'next-translate-plugin' )
module . exports = nextTranslate ( {
webpack : ( config , { isServer , webpack } ) => {
return config ;
}
} ) Fügen Sie eine Konfigurationsdatei i18n.json (oder i18n.js mit module.exports ) im Stammwurzel des Projekts hinzu. Jede Seite sollte ihre Namespaces haben. Schauen Sie sich es im Abschnitt Konfiguration an, um weitere Informationen zu erhalten.
{
"locales" : [ " en " , " ca " , " es " ],
"defaultLocale" : " en " ,
"pages" : {
"*" : [ " common " ],
"/" : [ " home " , " example " ],
"/about" : [ " about " ]
}
}In der Konfigurationsdatei können Sie sowohl die hier angegebene Konfiguration als auch die eigenen Funktionen zur Internationalisierung von Next.js 10 verwenden.
Standardmäßig werden die Namespaces auf diese Weise im Root -Verzeichnis /Lokale angegeben:
/Orte
.
├── ca
│ ├── common.json
│ └── home.json
├── en
│ ├── common.json
│ └── home.json
└── es
├── common.json
└── home.json Jeder Dateiname entspricht dem in der pages angegebenen Namespace, während jeder Dateiinhalt dem ähnlich sein sollte:
{
"title" : " Hello world " ,
"variable-example" : " Using a variable {{count}} "
}Sie können jedoch ein anderes Ziel verwenden, um Ihre Namespaces -Dateien mithilfe der LoadLocaleFrom -Konfigurationseigenschaft zu speichern:
i18n.js
{
// ...rest of config
"loadLocaleFrom" : ( lang , ns ) =>
// You can use a dynamic import, fetch, whatever. You should
// return a Promise with the JSON file.
import ( `./myTranslationsFiles/ ${ lang } / ${ ns } .json` ) . then ( ( m ) => m . default ) ,
}Verwenden Sie dann die Übersetzungen in der Seite und ihren Komponenten:
Seiten/Beispiel.js
import useTranslation from 'next-translate/useTranslation'
export default function ExamplePage ( ) {
const { t , lang } = useTranslation ( 'common' )
const example = t ( 'variable-example' , { count : 42 } )
return < div > { example } </ div > // <div>Using a variable 42</div>
}Sie können die Übersetzungen direkt auf Ihren Seiten konsumieren. Sie müssen sich keine Sorgen machen, dass die Namespaces -Dateien auf jeder Seite manuell geladen werden. Das Next-Translate-Plugin lädt nur die Namespaces, die die Seite benötigt, und nur mit der aktuellen Sprache.
In der Konfigurationsdatei können Sie sowohl die hier angegebene Konfiguration als auch die eigenen Funktionen zur Internationalisierung von Next.js 10 verwenden.
| Option | Beschreibung | Typ | Standard |
|---|---|---|---|
defaultLocale | ISO des Standardgebiets ("en" als Standard). | string | "en" |
locales | Ein Array mit allen Sprachen, die im Projekt verwendet werden sollen. | string[] | [] |
loadLocaleFrom | Ändern Sie die Art und Weise, wie Sie die Namespaces laden. | function , die ein Promise mit dem JSON zurückgibt. | Standardmäßig laden die Namespaces aus dem Root -Verzeichnis der Region . |
pages | Ein Objekt, das die in jeder Seite verwendeten Namespaces definiert. Beispiel für Objekt: {"/": ["home", "example"]} . So addieren Sie Namespaces zu allen Seiten, Sie sollten den Schlüssel "*" , z. B. {"*": ["common"]} . Es ist auch möglich, Regex mit rgx: vorne: {"rgx:/form$": ["form"]} . Sie können auch eine Funktion anstelle eines Arrays verwenden, um abhängig von einigen Regeln einige Namespaces anzugeben, z. B. { "/": ({ req, query }) => query.type === 'example' ? ['example'] : []} | Object<string[] or function> | {} |
logger | Funktionieren Sie, um die fehlenden Schlüssel in der Entwicklung und Produktion zu protokollieren. Wenn Sie i18n.json als Konfigurationsdatei verwenden, sollten Sie sie in i18n.js ändern. | function | Standardmäßig ist der Logger eine Funktion, die eine console.warn ausführt. WARN nur in der Entwicklung. |
loggerEnvironment | String, um zu definieren, ob der Logger im Browser im Knoten oder in beide ausgeführt wird | "node" | "browser" | "both" | "browser" |
logBuild | Jede Seite enthält ein Protokoll, das angibt: Namespaces, aktuelle Sprache und Methode zum Laden der Namespaces. Damit können Sie es deaktivieren. | Boolean | true |
loader | Wenn Sie den Webpack -Loader deaktivieren und die Namespaces auf jeder Seite manuell laden möchten, geben wir Ihnen die Möglichkeit, diese Option zu tun. | Boolean | true |
interpolation | Ändern Sie den Trennzeichen, der für die Interpolation verwendet wird. | {prefix: string; suffix: string, formatter: function } | {prefix: '{{', suffix: '}}'} |
keySeparator | Ändern Sie das Separator, das für verschachtelte Schlüssel verwendet wird. Legen Sie auf false fest, um Schlüssel in JSON -Übersetzungsdateien zu deaktivieren. Kann nützlich sein, wenn Sie natürlichen Text als Schlüssel verwenden möchten. | string | false | '.' |
nsSeparator | char, um den Namespace vom Schlüssel zu teilen. Sie sollten es auf false setzen, wenn Sie natürliche Text als Schlüssel verwenden möchten. | string | false | ':' |
defaultNS | Der Standard -Namespace wird verwendet, wenn es nicht an useTranslation oder im Übersetzungsschlüssel weitergegeben wird. | string | undefined |
staticsHoc | Die Hocs, die wir in unserer API haben (Appwithi18n), verwenden Sie keine Hodel-Non-React-Statics, um nicht mehr KB als notwendig zu enthalten (statische Werte, die sich als GetInitialProps auf den Seiten selten verwenden) . Wenn Sie Konflikte mit Statik haben, können Sie hier Hebezeug-Non-React-Statik (oder eine andere Alternative) hinzufügen. Siehe ein Beispiel. | Function | null |
extensionsRgx | Ändern Sie den von dem Webpack Loader verwendeten Regex, um die nächsten.js -Seiten zu finden. | Regex | /.(tsx|ts|js|mjs|jsx)$/ |
revalidate | Wenn Sie auf jeder Seite einen Standard -Neubeanspruchung haben möchten, geben wir Ihnen die Möglichkeit, dies zu tun, indem Sie eine Nummer zur Neubewertung geben. Sie können GetStaticProps auf einer Seite mit einem anderen Neuaufbaubetrag definieren und diese Standardüberschreibung überschreiben. | Number | Wenn Sie es nicht definieren, haben die Seiten standardmäßig nicht neu. |
pagesInDir | my-app/pages Sie next ./my-app ausführen. | String | Wenn Sie es nicht definieren, werden die Seiten standardmäßig an klassischen Stellen wie pages und src/pages gesucht. |
localesToIgnore | Geben Sie diese Orte an, um zu ignorieren, wenn Sie das Standardgebiet mithilfe einer Middleware Präfixen (im nächsten +12, erfahren Sie, wie es geht). | Array<string> | ['default'] |
allowEmptyStrings | Ändern Sie, wie übersetzte leere Saiten behandelt werden sollten. Wenn es als wahr ausgelassen oder als wahr bestanden wird, gibt es eine leere Zeichenfolge zurück. Wenn Sie als falsch bestanden werden, gibt der Schlüsselname selbst (einschließlich NS) zurück. | Boolean | true |
Größe : ~ 150b?
Dieser Haken ist die empfohlene Möglichkeit, Übersetzungen auf Ihren Seiten / Komponenten zu verwenden.
Beispiel:
import React from 'react'
import useTranslation from 'next-translate/useTranslation'
export default function Description ( ) {
const { t , lang } = useTranslation ( 'ns1' ) // default namespace (optional)
const title = t ( 'title' )
const titleFromOtherNamespace = t ( 'ns2:title' )
const description = t `description` // also works as template string
const example = t ( 'ns2:example' , { count : 3 } ) // and with query params
const exampleDefault = t ( 'ns:example' , { count : 3 } , { default : "The count is: {{count}}." } ) // and with default translation
return (
< >
< h1 > { title } </ h1 >
< p > { description } </ p >
< p > { example } </ p >
< >
)
} Die t -Funktion:
i18nKey eingebettet ist. Ähnlich als useTranslation , aber ohne ein Haken. Dieser Helfer funktioniert nur in App Dir .
const { t , lang } = createTranslation ( 'ns1' ) // default namespace (optional)
const title = t ( 'title' )Größe : ~ 560b?
Es ist eine Alternative zum useTranslation , aber in einem Hoc für diese Komponenten, die nicht funktionsfähig sind. (Nicht empfohlen, es ist besser, den useTranslation zu verwenden.) .
Das withTranslation hoc gibt eine Komponente mit einer zusätzlichen Requisitin mit dem Namen i18n zurück (Objekt {T: Funktion, Lang: String}).
Beispiel:
import React from 'react'
import withTranslation from 'next-translate/withTranslation'
class Description extends React . Component {
render ( ) {
const { t , lang } = this . props . i18n
const description = t ( 'common:description' )
return < p > { description } </ p >
}
}
export default withTranslation ( NoFunctionalComponent ) Ähnlich wie bei useTranslation("common") können Sie mit dem zweiten Parameter, der einen Standard -Namespace definiert, withTranslation , um zu verwenden:
export default withTranslation(NoFunctionalComponent, "common")
Größe : ~ 1,4 KB?
Manchmal müssen wir einige Übersetzungen mit HTML im Text (fett, Links usw.) durchführen, die Trans ist genau das, was Sie dafür benötigen. Wir empfehlen, diese Komponente nur in diesem Fall zu verwenden. Für andere Fälle empfehlen wir stattdessen die Verwendung von useTranslation Hook.
Beispiel:
// The defined dictionary entry is like:
// "example": "<0>The number is <1>{{count}}</1></0>",
< Trans
i18nKey = "common:example"
components = { [ < Component /> , < b className = "red" /> ] }
values = { { count : 42 } }
/> Oder verwenden components als Objekt:
// The defined dictionary entry is like:
// "example": "<component>The number is <b>{{count}}</b></component>",
< Trans
i18nKey = "common:example"
components = { {
component : < Component /> ,
b : < b className = "red" /> ,
} }
values = { { count : 42 } }
defaultTrans = "<component>The number is <b>{{count}}</b></component>"
/>i18nKey - String - Schlüssel des i18n -Eintrags (Namespace: Schlüssel)components - Array | Objekt - Bei Array entspricht jeder Index dem definierten Tag <0> / <1> . Im Falle von Objekt entspricht jeder Schlüssel dem definierten Tag <example> .values - Objekt - Abfrageparameterfallback - String | String [] - Optional. Fallback i18nkey Wenn der i18nkey nicht passt.defaultTrans - String - Standardübersetzung für den Schlüssel. Wenn Fallback -Tasten verwendet werden, wird es nur nach Erschöpfung aller Fallbacks verwendet.ns - Namespace zu verwenden, wenn keiner in i18nKey eingebettet istreturnObjects - boolean - Holen Sie sich mit allen Übersetzungen einen Teil des JSON. Sehen Sie mehr. In Fällen, in denen wir die Funktionalität der Trans erfordern, aber eine String , die interpoliert werden muss, und nicht die Ausgabe der Funktion t(props.i18nKey) , gibt es auch eine TransText -Komponente, die eine text -Requisite anstelle von i18nKey nimmt.
text - Zeichenfolge - Die Zeichenfolge, die (optional) Tags enthält, die Interpolation erforderncomponents - Array | Objekt - Dies verhält sich genauso wie Trans (siehe oben). Dies ist besonders nützlich, wenn Sie die Ausgabe von a t() mit returnObjects: true :
// The defined dictionary entry is like:
// "content-list": ["List of <link>things</link>", "with <em>tags</em>"]
const contentList = t ( 'someNamespace:content-list' , { } , { returnObjects : true } ) ;
{ contentList . map ( ( listItem : string ) => (
< TransText
text = { listItem }
components = { {
link : < a href = "some-url" /> ,
em : < em /> ,
} }
/>
) }Größe : ~ 1,5 KB?
Die DynamicNamespaces -Komponente ist nützlich, um dynamische Namespaces beispielsweise in Modalen zu laden.
Beispiel:
import React from 'react'
import Trans from 'next-translate/Trans'
import DynamicNamespaces from 'next-translate/DynamicNamespaces'
export default function ExampleWithDynamicNamespace ( ) {
return (
< DynamicNamespaces namespaces = { [ 'dynamic' ] } fallback = "Loading..." >
{ /* ALSO IS POSSIBLE TO USE NAMESPACES FROM THE PAGE */ }
< h1 >
< Trans i18nKey = "common:title" />
</ h1 >
{ /* USING DYNAMIC NAMESPACE */ }
< Trans i18nKey = "dynamic:example-of-dynamic-translation" />
</ DynamicNamespaces >
)
} Denken Sie daran, dass ['dynamic'] Namespace nicht in der Konfiguration pages aufgeführt sein sollte:
pages: {
'/my-page' : [ 'common' ] , // only common namespace
}namespaces - String [] - Liste dynamischer Namespaces zum Herunterladen - Erforderlich .fallback - ReactNode - Fallback zum Anzeigen der Namespaces laden inzwischen. - optional .dynamic - Funktion - Standardmäßig verwendet das LoadLocaleFrom in der Konfiguration, um die Namespaces zu laden, aber Sie können ein anderes Ziel angeben. - optional .Größe : ~ 1,3 KB?
Asynchrone Funktion zum Laden der t -Funktion externe Komponenten / Seiten. Es funktioniert sowohl auf serverseitig als auch auf clientseitig.
Im Gegensatz zum USETRANSLATION -Hook können wir hier einen Namensbereich verwenden. Es muss kein Namespace sein, der in der Konfiguration "Seiten" definiert ist. Es lädt den als Parameter angegebenen Namespace auf der Laufzeit herunter.
Sie können mehrere Namespaces laden, indem Sie ein Array als Parameter angeben. In diesem Fall ist der Standard -Namespace die Faust.
Beispiel in Inside getStaticProps :
import getT from 'next-translate/getT'
// ...
export async function getStaticProps ( { locale } ) {
const t = await getT ( locale , 'common' )
const title = t ( 'title' )
return { props : { title } }
}Beispiel in der API -Route:
import getT from 'next-translate/getT'
export default async function handler ( req , res ) {
const t = await getT ( req . query . __nextLocale , 'common' )
const title = t ( 'title' )
res . statusCode = 200
res . setHeader ( 'Content-Type' , 'application/json' )
res . end ( JSON . stringify ( { title } ) )
}Beispiel für das Laden mehrerer Namespaces:
import getT from 'next-translate/getT'
export default async function handler ( req , res ) {
const t = await getT ( req . query . __nextLocale , [ 'common' , 'errors' ] )
const title = t ( 'title' ) // The default namespace is the first one.
const errorMessage = t ( 'errors:app_error' ) // The default namespace is the first one.
res . statusCode = 200
res . setHeader ( 'Content-Type' , 'application/json' )
res . end ( JSON . stringify ( { title } ) )
}Größe : ~ 3 KB?
Der I18nProvider ist ein Kontextanbieter, der intern von Next-Translate verwendet wird, um den aktuellen Lang und die Seitennamenspaces bereitzustellen. Vielleicht wirst du das nie brauchen .
Es ist jedoch der API ausgesetzt, da sie in einigen Fällen nützlich sein kann. Zum Beispiel, um mehrsprachige Übersetzungen auf einer Seite zu verwenden.
Der I18nProvider sammelt die Namespaces an, sodass Sie die neuen umbenennen können, um die alten zu halten.
import React from 'react'
import I18nProvider from 'next-translate/I18nProvider'
import useTranslation from 'next-translate/useTranslation'
// Import English common.json
import commonEN from '../../locales/en/common.json'
function PageContent ( ) {
const { t , lang } = useTranslation ( )
console . log ( lang ) // -> current language
return (
< div >
< p > { t ( 'common:example' ) /* Current language */ } </ p >
< p > { t ( 'commonEN:example' ) /* Force English */ } </ p >
</ div >
)
}
export default function Page ( ) {
const { lang } = useTranslation ( )
return (
< I18nProvider lang = { lang } namespaces = { { commonEN } } >
< PageContent />
</ I18nProvider >
)
}Größe : ~ 3,7 KB?
Die appWithI18n wird intern von der nächsten Übertragung verwendet. Vielleicht wirst du das nie brauchen . Wir setzen es jedoch in der API auf, falls Sie die Option Webpack Loader deaktivieren und entscheiden, die Namespaces manuell zu laden.
Wenn Sie den WebPack Loader nicht verwenden möchten, sollten Sie diese in Ihre _app.js -Datei einfügen (und die Datei _app.js erstellen, wenn Sie sie nicht haben).
Beispiel:
_app.js
import appWithI18n from 'next-translate/appWithI18n'
import i18nConfig from '../i18n'
function MyApp ( { Component , pageProps } ) {
return < Component { ... pageProps } />
}
// Wrapping your _app.js
export default appWithI18n ( MyApp , {
... i18nConfig ,
// Set to false if you want to load all the namespaces on _app.js getInitialProps
skipInitialProps : true ,
} ) Wenn skipInitialProps=true , sollten Sie auch den Helfer für LoadNamePaces verwenden, um die Namespaces auf jeder Seite manuell zu laden.
Größe : ~ 1,9 KB?
Die loadNamespaces werden intern von der nächsten Übertragung verwendet. Vielleicht wirst du das nie brauchen . Wir setzen es jedoch in der API auf, falls Sie die Option Webpack Loader deaktivieren und entscheiden, die Namespaces manuell zu laden.
Um die Namespaces zu laden, müssen Sie die von dem Helfer bereitgestellten Requisiten auf Ihre Seiten zurückgeben.
import loadNamespaces from 'next-translate/loadNamespaces'
export function getStaticProps ( { locale } ) {
return {
props : {
... ( await loadNamespaces ( { locale , pathname : '/about' } ) ) ,
}
}
} Um gut zu funktionieren, ist es notwendig, dass Ihr _app.js mit der Appwithi18n verpackt wird. Außerdem ist die loadLocaleFrom -Konfigurationseigenschaft obligatorisch , um sie zu definieren.
Wir unterstützen 6 Pluralformen (entnommen von CLDR Plurals -Seite), indem wir den Schlüssel dieses Suffix (oder verhindern Sie es unter dem Schlüssel ohne _ ):
_zero_one (Singular)_two (dual)_few (paukal)_many (auch für Brüche verwendet, wenn sie eine separate Klasse haben)_other (erforderlich - allgemeine Pluralform - auch verwendet, wenn die Sprache nur eine einzelne Form hat)Weitere Informationen zu Pluralen finden Sie hier .
Es ist nur der letzte, _other , erforderlich ist, da es die einzige gemeinsame Pluralform ist, die in allen Orten verwendet wird.
Alle anderen Pluralformen hängen vom Gebietsschema ab. Zum Beispiel hat Englisch nur zwei: _one und _other (1 Cat vs. 2 Katzen). Einige Sprachen haben mehr, wie Russisch und Arabisch.
Darüber hinaus unterstützen wir eine genaue Übereinstimmung , indem wir die Nummer ( _0 , _999 ) angeben, und dies funktioniert für alle Orte. Hier ist ein Beispiel:
Code:
// **Note**: Only works if the name of the variable is {{count}}.
t ( 'cart-message' , { count } )Namespace:
{
"cart-message_0" : "The cart is empty" , // when count === 0
"cart-message_one" : "The cart has only {{count}} product" , // singular
"cart-message_other" : "The cart has {{count}} products" , // plural
"cart-message_999" : "The cart is full" , // when count === 999
}oder
{
"cart-message" : {
"0" : "The cart is empty" , // when count === 0
"one" : "The cart has only {{count}} product" , // singular
"other" : "The cart has {{count}} products" , // plural
"999" : "The cart is full" , // when count === 999
}
}Intl.PluralRules -API ist nur für moderne Browser verfügbar . Wenn Sie sie in Legacy -Browsern verwenden möchten, sollten Sie eine Polyfill hinzufügen.
Sie können HTML in der Übersetzung auf diese Weise definieren:
{
"example-with-html" : " <0>This is an example <1>using HTML</1> inside the translation</0> "
}Beispiel:
import Trans from 'next-translate/Trans'
// ...
const Component = ( props ) => < p { ... props } />
// ...
< Trans
i18nKey = "namespace:example-with-html"
components = { [ < Component /> , < b className = "red" /> ] }
/ >Ergebnis: Ergebnis:
< p > This is an example < b class =" red " > using HTML </ b > inside the translation </ p > Jeder Index der components -Array entspricht <index></index> der Definition.
In dem components -Array ist es nicht erforderlich, die Kinder jedes Elements zu übergeben. Kinder werden berechnet.
Im Namespace ist es möglich, verschachtelte Schlüssel wie folgt zu definieren:
{
"nested-example" : {
"very-nested" : {
"nested" : " Nested example! "
}
}
}Um es zu verwenden, sollten Sie "". " als ID -Separator:
t `namespace:nested-example.very-nested.nested`Kann auch als Array verwendet werden:
{
"array-example" : [
{ "example" : " Example {{count}} " },
{ "another-example" : " Another example {{count}} " }
]
} Und erhalten Sie alle Array -Übersetzungen mit der Option returnObjects :
t ( 'namespace:array-example' , { count : 1 } , { returnObjects : true } )
/*
[
{ "example": "Example 1" },
{ "another-example": "Another example 1" }
]
*/ Außerdem ist es möglich, alle Übersetzungen durch die Verwendung des Schlüsselseparators als Schlüssel zu erhalten. Standard ist '.' :
t ( 'namespace:.' , { count : 1 } , { returnObjects : true } )
/*
{
"array-example": [
{ "example": "Example 1" },
{ "another-example": "Another example 1" }
]
}
*/ Wenn keine Übersetzung vorhanden ist, können Sie Fallbacks ( string|string[] ) definieren, um nach anderen Übersetzungen zu suchen:
const { t } = useTranslation ( )
const textOrFallback = t (
'ns:text' ,
{ count : 1 } ,
{
fallback : 'ns:fallback' ,
}
)Liste der Fallbacks:
const { t } = useTranslation ( )
const textOrFallback = t (
'ns:text' ,
{ count : 42 } ,
{
fallback : [ 'ns:fallback1' , 'ns:fallback2' ] ,
}
)In transkomponenten:
< Trans
i18nKey = "ns:example"
components = { [ < Component /> , < b className = "red" /> ] }
values = { { count : 42 } }
fallback = { [ 'ns:fallback1' , 'ns:fallback2' ] } // or string with just 1 fallback
/> Sie können Parameter mithilfe der interpolation.format -Konfigurationsfunktion formatieren.
in i18n.js :
const formatters = {
es : new Intl . NumberFormat ( "es-ES" ) ,
en : new Intl . NumberFormat ( "en-EN" ) ,
}
return {
// ...
interpolation : {
format : ( value , format , lang ) => {
if ( format === 'number' ) return formatters [ lang ] . format ( value )
return value
}
}
}Im englischen Namespace:
{
"example" : " The number is {{count, number}} "
}Im spanischen Namespace:
{
"example" : " El número es {{count, number}} "
}Verwendung:
t ( 'example' , { count : 33.5 } )Rückgaben:
The number is 33.5El número es 33,5 Um die aktuelle Sprache zu ändern, können Sie die nächste.JS -Navigation (Link und Router) verwenden, um die locale -Stütze zu übermitteln.
Ein Beispiel für eine mögliche ChangeLanguage -Komponente, die den useRouter -Hook von Next.js verwendet:
import React from 'react'
import Link from 'next/link'
import useTranslation from 'next-translate/useTranslation'
import i18nConfig from '../i18n.json'
const { locales } = i18nConfig
export default function ChangeLanguage ( ) {
const { t , lang } = useTranslation ( )
return locales . map ( ( lng ) => {
if ( lng === lang ) return null
return (
< Link href = "/" locale = { lng } key = { lng } >
{ t ( `layout:language-name- ${ lng } ` ) }
</ Link >
)
} )
} Sie können setLanguage auch verwenden, um die Sprache zu ändern, während Sie dieselbe Seite behalten.
import React from 'react'
import setLanguage from 'next-translate/setLanguage'
export default function ChangeLanguage ( ) {
return (
< button onClick = { async ( ) => await setLanguage ( 'en' ) } > EN </ button >
)
} Eine andere Möglichkeit, auf die Liste locales zuzugreifen, um die Sprache zu ändern, besteht darin, den Next.js router zu verwenden. Auf die Liste locales kann mit dem nächsten.js -Userouter -Hook zugegriffen werden.
Sie können ein Cookie namens NEXT_LOCALE mit der benutzerdefinierten Sprache als Wert festlegen. Auf diese Weise kann ein Gebietsschema erzwungen werden.
Beispiel von Hook:
import { useRouter } from 'next/router'
// ...
function usePersistLocaleCookie ( ) {
const { locale , defaultLocale } = useRouter ( )
useEffect ( persistLocaleCookie , [ locale , defaultLocale ] )
function persistLocaleCookie ( ) {
if ( locale !== defaultLocale ) {
const date = new Date ( )
const expireMs = 100 * 24 * 60 * 60 * 1000 // 100 days
date . setTime ( date . getTime ( ) + expireMs )
document . cookie = `NEXT_LOCALE= ${ locale } ;expires= ${ date . toUTCString ( ) } ;path=/`
}
}
} In einigen Fällen möchten Sie, wenn sich die Seite in der aktuellen Sprache befindet, einige Ausnahmen durchführen, die einen Text in einer anderen Sprache anzeigen.
In diesem Fall können Sie dies erreichen, indem Sie den I18nProvider verwenden.
Erfahren Sie, wie es hier geht.
Nächstes Translate verwendet standardmäßig das aktuelle Arbeitsverzeichnis des Node.js-Prozesses ( process.cwd() ).
Wenn Sie es ändern möchten, können Sie verwenden:
NEXT_TRANSLATE_PATH . Es unterstützt sowohl den relativen als auch den absoluten Wegprocess.chdir(PATH_TO_NEXT_TRANSLATE) um den process.cwd() Wenn es um Serverkomponenten und Client -Komponenten geht, kann es schwierig sein, dasselbe auf verschiedenen Seiten zu laden. Um diesen Prozess zu vereinfachen, haben wir die gesamte Komplexität unter Verwendung des next-translate-plugin extrahiert.
Wenn Sie mehr darüber erfahren möchten, wie die nächste Translate mit dem neuen Next.JS 13 App Dir Paradigma funktioniert, finden Sie in diesem Artikel eine detaillierte Erklärung.
Wenn Sie den Ordner "App" anstelle des Ordners "Seiten" verwenden, erkennt das next-translate-plugin die Änderung automatisch und Sie müssen keine der nächsten Übertragungskonfiguration berühren. Der einzige Unterschied besteht darin, dass die Konfigurationseigenschaft "Seiten" auf die Seiten im Ordner "App" verweist.
i18n.js
module . exports = {
locales : [ 'en' , 'ca' , 'es' ] ,
defaultLocale : 'en' ,
pages : {
'*' : [ 'common' ] ,
'/' : [ 'home' ] , // app/page.tsx
'/second-page' : [ 'home' ] , // app/second-page/page.tsx
} ,
} Indem Sie einfach den Ordner "Seiten" in "App" ändern, können Sie Übersetzungen in Ihren Seiten mit dem useTranslation Hook oder der Trans -Komponente konsumieren. Sie werden weiterhin das Protokoll (falls aktiviert) sehen, um zu wissen, welche Namespaces auf jeder Seite geladen sind, und alles andere sollte gleich sein.
? Serverseite/Komponente (+0KB): app/page.js :
import useTranslation from 'next-translate/useTranslation'
export default function HomePage ( ) {
const { t , lang } = useTranslation ( 'home' )
return < h1 > { t ( 'title' ) } </ h1 >
} app/checkout/page.js
"use client"
import useTranslation from 'next-translate/useTranslation'
export default function CheckoutPage ( ) {
const { t , lang } = useTranslation ( 'checkout' )
return < h1 > { t ( 'title' ) } </ h1 >
} NEXT.JS 10 Einführte I18N-Routing-Unterstützung, sodass Seiten durch Navigieren zu /es/page-name gerendert werden können, wobei auf die pages/page-name.js mit dem useRouter Haken zugegriffen wurde, um das locale zu erhalten.
Da die Seiten jedoch von den pages DIR auf die App DIR verschoben wurden, funktioniert dieses i18n -Routing nicht mehr richtig .
Bei der nächsten Translate haben wir uns entschlossen, diese Funktionalität nicht erneut zu implementieren, da wir eine Bibliothek für die Übersetzung von Seiten sein wollen, anstatt sie zu leiten. Wir hoffen, dass diese Funktion in Zukunft im app -Verzeichnis implementiert wird.
Wir empfehlen Folgendes:
[lang] in die erste Ebene hinzu. Das heißt, alle Ihre Seiten befinden sich in /app/[lang] .i18n.(js|json) um die /[lang] am Anfang zu enthalten. module.exports = {
locales: ['en', 'ca', 'es'],
defaultLocale: 'en',
pages: {
'*': ['common'],
- '/': ['home'],
+ '/[lang]': ['home'],
- '/second-page': ['home'],
+ '/[lang]/second-page': ['home'],
},
} Auf der Ebene der nächsten Translate erkennen wir die Sprache bereits automatisch gemäß searchParams.get('lang') und params.lang . Sie müssen es also nicht für jede Seite konfigurieren . Sie können als normal auf den Server-/Client-Seiten/-komponenten als next-translate verwendet werden:
import useTranslation from 'next-translate/useTranslation'
import Trans from 'next-translate/Trans'
export default function Page ( ) {
const { t , lang } = useTranslation ( 'common' )
return (
< >
< h1 > { t `title` } </ h1 >
< Trans i18nKey = "common:another-text" components = { [ < b /> ] } />
</ >
)
} Es gibt eine Demo von next-translate im nächsten.js Repo:
Um es zu verwenden:
npx create-next-app --example with-next-translate with-next-translate-app
# or
yarn create next-app --example with-next-translate with-next-translate-appDiese Demo befindet sich in diesem Repository:
git clone [email protected]:aralroca/next-translate.gitcd next-translateyarn && yarn example:basicÄhnlich wie die grundlegende Demo, jedoch mit einigen Extras: TypeScript, Webpack 5, MDX, mit _app.js oben, Seiten im Ordner SRC/Pages, laden Lokales von SRC/Übersetzungen mit einer anderen Struktur.
Diese Demo befindet sich in diesem Repository:
git clone [email protected]:aralroca/next-translate.gitcd next-translateyarn && yarn example:complex Ähnlich wie die komplexe Demo, aber mit einigen zusätzlichen: anstelle des pages verwenden wir den nächsten.js +13 -App -Ordner mit dem neuen Layout -System.
Diese Demo befindet sich in diesem Repository:
git clone [email protected]:aralroca/next-translate.gitcd next-translateyarn && yarn example:with-app-directoryÄhnlich wie das grundlegende Beispiel, aber das Laden der Seitennamenspaces manuell deaktiviert, um den Webpack -Loader in der Konfigurationsdatei i18n.json zu deaktivieren.
Wir empfehlen nicht, dass es auf diese Weise verwendet wird. Wir geben jedoch jedem die Möglichkeit, dies zu tun, wenn er mit unserem Webpackloader nicht vertraut ist.
Diese Demo befindet sich in diesem Repository:
git clone [email protected]:aralroca/next-translate.gitcd next-translateyarn && yarn example:without-loader Vielen Dank an diese wunderbaren Menschen (Emoji -Schlüssel):
Aral Roca Gomez ? | Vincent Ducorps | Björn Rave | Justin | Pol ? | ADEMílson F. Tonato | Faul |
Bickmaev5 | Pierre Grimaud | Roman Minchyn | Egor | Darren | Giovanni Giordano | Eugene |
Andrew Chung | Thanh Minh | Crouton | Patrick | VanTroy | Joey | Gurkerl83 |
Teemu Perämäki | Luis Serrano | J-Schumann | Andre Hsu | Slevy85 | Bernd Artmüller | Rihards Ščeredins |
N4N5 | Rubén Moya | Tom Estenez | Dan Needham | Bruno Antunes | Kaan Atakan | Romain |
Arnau Jiménez | Edwin Veldhuizen | Duc ngo viet | Billel Helali | Wuif | Michał Bar | Wuif |
Marces Engel | Michał Bar | Schleppen | Marces Engel | Vasco Silva | VSEVOLOD Volkov | Felix Yan |
Muhammad Al Ziqri | Marcelo Oliveira | Zack Sunderland | Andrew -Öfen | Dani | Mateusz Lesiak | Curetix |
Honza ? | Hardikbandhiya | Tim O. Peters | Li ming | Fernando García Hernández | Hichem Fantar | Huseyin onal |
Jesse Martin |
Dieses Projekt folgt der All-Contributors-Spezifikation. Beiträge jeglicher Art willkommen!
