Internationalisierung

Füge deiner App Mehrsprachigkeit hinzu. Nutze die Proyecta Content API für redaktionelle Lokalisierung oder bitte die KI, ein i18n-Framework direkt im Code einzurichten.

Proyecta unterstützt zwei sich ergänzende Ansätze zur Internationalisierung der Apps, die du damit baust:

1. Inhaltslokalisierung über die Proyecta Content API — für redaktionelle Inhalte (Blogbeiträge, FAQs, Marketingtexte), die in mehrere Sprachen übersetzt werden sollen
2. Code-seitiges i18n über ein Übersetzungs-Framework — für UI-Texte, Datumsangaben, Währungen und das Umschalten der Sprache zur Laufzeit

Beide Ansätze funktionieren bereits heute. Welchen du benötigst, hängt davon ab, was du übersetzen möchtest.

Proyecta selbst wird in 24 Sprachen ausgeliefert – das Produkt ist also bestens mit i18n vertraut. Dieselben Muster lassen sich auf die Apps anwenden, die du darin baust.

Option 1: Inhaltslokalisierung (Proyecta Content API)

Wenn du eine inhaltsreiche Website baust – Blog, Wissensdatenbank, Marketingseiten, Produktkatalog – nutze die integrierte Locale-Unterstützung. Sag der KI, welche Sprachen du unterstützt ("Make the site available in English, Spanish and French"), und sie registriert sie für dich, mit Englisch als Standard. Anschließend rufst du deine Inhalte in der Sprache des Besuchers ab.

Im Frontend lösen die typisierten Content-Hooks des Templates lokalisierte Felder automatisch für dich auf – übergib die aktive Sprache des Besuchers, und jedes localized-Feld liefert direkt den übersetzten Wert zurück:

import { useCollection, useEntry } from '@/hooks/useContent';
import { useTranslation } from 'react-i18next';

function Blog({ slug }: { slug: string }) {
    const { i18n } = useTranslation();

    // List a collection in the current locale
    const { data: posts } = useCollection('posts', { locale: i18n.language });

    // Or read one entry by slug in the current locale
    const { data: post } = useEntry('posts', slug, { locale: i18n.language });

    // ...render posts / post
}

Im Hintergrund durchläuft das CMS eine Fallback-Kette – die angeforderte Sprache → ihre konfigurierten Fallbacks → die Standardsprache – und gibt auf jedem Eintrag als localeResolved an, welcher Code tatsächlich geliefert wurde. Lässt du locale bei einsprachigen Seiten weg, werden die Felder als Rohwerte zurückgegeben.

Dies ist der richtige Ansatz, wenn:

• Redakteure ohne Programmierkenntnisse Inhalte übersetzen müssen
• du möchtest, dass Übersetzungen versionierbar sind
• du sprachspezifische Veröffentlichungen benötigst (zeitgesteuerte Veröffentlichung kommt bald – Einträge erfordern derzeit eine manuelle Veröffentlichung über die API)

Unter Content Management findest du die vollständige Content API-Dokumentation.

Option 2: Code-seitiges i18n-Framework

Für UI-Texte – Labels, Buttons, Fehlermeldungen, Datumsangaben, Währungen – bitte die KI, ein i18n-Framework direkt in dein Projekt einzurichten:

Add internationalization to my app.
Support English, Spanish, French, and Arabic.
Add message catalogs in src/locales/.
Add a language switcher in the header.
Use locale-prefixed URLs like /en/about and /es/about.
Make sure RTL layout works correctly for Arabic.

Die KI wird:

1. Ein Framework auswählen — die KI verwendet i18next mit react-i18next (Proyectas Standard)
2. Katalogdateien erstellen in src/locales/ (eine JSON-Datei pro Sprache)
3. Texte einwickeln in t()-Aufrufe (aus dem useTranslation-Hook von react-i18next)
4. Eine Sprachumschaltkomponente hinzufügen
5. URL-Routing mit Sprachpräfixen einrichten
6. RTL-Layouts (dir="rtl") für Arabisch, Hebräisch usw. behandeln
7. Zahlen, Datumsangaben und Währungen sprachspezifisch formatieren

Automatisch übersetzen mit der KI

Sobald deine Ausgangssprache steht, ist die KI hervorragend geeignet, um die übrigen Katalogdateien zu erstellen:

• "Translate every string in src/locales/en.json into Spanish, French, German, and Japanese. Use natural, idiomatic phrasing — don't translate brand names."
• "My app is fully built in English. Add Spanish translations for everything and an es/ route prefix."

Bei sensiblen Inhalten (rechtliche Texte, Medizin, Finanzen) sollte ein menschlicher Übersetzer die KI-Ausgabe vor der Veröffentlichung prüfen.

Beide Ansätze kombinieren

Die meisten realen Apps nutzen beide Ansätze: Code-seitiges i18n für das UI-Gerüst (Buttons, Fehlermeldungen, Navigation) und die Content API für redaktionelle Inhalte (Artikel, Produktbeschreibungen). Sie koexistieren problemlos – dein i18n-Framework verarbeitet die Katalogdateien zur Build-Zeit, während die Content API lokalisierte Einträge zur Laufzeit liefert.

Best Practices

1. Lege zuerst deine Ausgangssprache und die Texte fest. Ein sich ständig änderndes Ziel zu übersetzen ist mühsam.
2. Übersetzungen bündeln. Übersetze nicht fortlaufend – warte, bis ein Feature stabil ist.
3. RTL frühzeitig testen, wenn du Arabisch oder Hebräisch unterstützt. RTL-Fehler fallen erst auf, wenn man gezielt danach schaut.
4. lang und dir am <html>-Element angeben. Browser und Screenreader sind darauf angewiesen.
5. Intl für die Formatierung verwenden. Datum- oder Währungsformatierung nicht selbst implementieren – nutze Intl.DateTimeFormat und Intl.NumberFormat.

Demnächst verfügbar

• Locale-Verwaltungs-UI im Builder — Sprachen auswählen, Übersetzungsabdeckung einsehen und Kataloge bearbeiten, ohne Proyecta zu verlassen
• Automatische Übersetzung beim Speichern für neue Texte
• i18n-fähige Projektvorlagen mit voreingerichtetem Framework