gt-next@6.3.0
Übersicht
In gt-next 6.3.0 nähern wir uns einer Bibliothek, die sowohl für menschliche Entwickler als auch für KI‑Entwickler geeignet ist. Unser Leitprinzip für dieses Release war, Änderungen am bestehenden Code so gering wie möglich zu halten, während wir dennoch die wesentliche Funktionalität für i18n einführen.
Um dies zu erreichen, führen wir eine neue msg()-Funktion ein, mit der sich Strings überall in Ihrem Code übersetzen lassen. Bisher mussten Entwickler die t()-Funktion aus useGT() oder getGT() den Call-Stack hinaufreichen, um einen String zu übersetzen. Mit msg() umschließen Sie den String einfach einmal und geben ihn dann zur Renderzeit an m() weiter.
Ein Vergleich
Früher mussten Strings übersetzt werden, indem die t()-Funktion durch mehrere Ebenen weitergereicht wurde:
export const greeting1 = 'Hallo, Welt!'
export const getGreeting2 = (t: any) => t('Hallo, Welt!')import { greeting1, getGreeting2 } from './constants'
export default function Page() {
const t = useGT()
return (
<div>
{greeting1}
{getGreeting2(t)}
</div>
)
}Mit msg() können Strings jetzt direkt als Konstanten deklariert werden. Die einzige Voraussetzung ist, dass du sie beim Anzeigen durch m() (aus useMessages() oder getMessages()) laufen lässt.
export const greeting1 = 'Hallo, Welt!'
export const greeting2 = msg('Hallo, Welt!')import { greeting1, greeting2 } from './constants'
export default function Page() {
const m = useMessages()
return (
<div>
{greeting1}
{m(greeting2)}
</div>
)
}Encoding und Decoding
Um Interpolation zu unterstützen, gibt die msg()-Funktion eine encodete Nachricht statt eines einfachen Strings zurück. Das Format sieht so aus:
<interpolierter Inhalt>:<base64-kodierte Zeichenkette>Der base64-codierte Teil enthält ein JSON-Objekt mit:
$_hash: Hash des ursprünglichen Strings$_source: In die Nachricht interpolierte Parameter$id: Eine benutzerdefinierte eindeutige Kennung (falls angegeben)$context: Kontext der Nachricht (falls angegeben)- Allen in der Interpolation enthaltenen Variablen
Dieses Design verändert leicht, wie Strings direkt miteinander verglichen werden, sorgt aber dafür, dass die Auswirkungen auf Typisierung und Codestruktur minimal bleiben. Um auf den interpolierten Inhalt zuzugreifen, verwende decodeMsg().
Warum ein codierter String?
Die Alternative zur Verwendung eines codierten Strings wäre, dass msg() einen benutzerdefinierten Objekttyp zurückgeben müsste, der die zusätzlichen Metadaten enthält. Zwar funktioniert das für das Encode/Decode‑Paradigma, es führt jedoch zu Problemen bei strenger Typisierung.
Wir sind zu dem Schluss gekommen, dass die beste Möglichkeit, die Auswirkungen von i18n in diesem Szenario zu minimieren, darin besteht, stattdessen einfach einen String zurückzugeben, der die Metadaten enthält.
Beispiel
Originalcode ohne i18n:
const name = 'John'
const message = `Hello, ${name}!`
if (message.length > 10) {
console.log('Die Nachricht ist zu lang')
} else {
console.log('Die Nachricht hat die richtige Länge')
}Mit msg() und decodeMsg():
import { msg, decodeMsg } from 'gt-next'
const name = 'John'
const message = msg('Hallo, {name}!', { name })
if (decodeMsg(message).length > 10) {
console.log('Die Nachricht ist zu lang')
} else {
console.log('Die Nachricht hat genau die richtige Länge')
}Sonstiges
Du kannst Parameter auch innerhalb der Funktion t() überschreiben, selbst wenn sie beim Aufruf von msg() bereits interpoliert worden sind.
import { msg, useMessages } from 'gt-next'
const message = msg('Hallo, {name}!', { name: 'John' })
export default function Page() {
const m = useMessages()
return <div>{m(message, { name: 'Jane' })}</div> // Dies gibt „Hallo, Jane!" zurück
}Zusammenfassung
Dieses Release konzentriert sich darauf, gt-next noch entwicklerfreundlicher zu machen und gleichzeitig den i18n‑Overhead zu minimieren. Indem die Notwendigkeit entfällt, die Funktion t() durch den Call-Stack zu reichen, bietet die neue Funktion msg() eine übersichtlichere, intuitivere Möglichkeit, Strings zu übersetzen, und vereinfacht den i18n-Prozess erheblich.