Internationalisering

Lägg till flerspråksstöd i din app. Använd Proyecta Content API för redaktionell lokalisering, eller be AI:n att koppla in ett i18n-ramverk direkt i koden.

Proyecta stöder två kompletterande tillvägagångssätt för att internationalisera de appar du bygger:

1. Innehållslokalisering via Proyecta Content API — för redaktionellt innehåll (blogginlägg, vanliga frågor, marknadsföringstext) som behöver översättas till flera språk
2. Kodbaserad i18n via ett översättningsramverk — för UI-strängar, datum, valutor och byte av locale under körning

Båda fungerar redan idag. Vilket du behöver beror på vad du ska översätta.

Proyecta som builder levereras med 24 locales, så produkten är van vid i18n. Samma mönster gäller för de appar du bygger i den.

Alternativ 1: Innehållslokalisering (Proyecta Content API)

Om du bygger en innehållstung sajt — blogg, kunskapsbas, marknadsföringssidor, produktkatalog — använd det inbyggda stödet för locales. Berätta för AI:n vilka språk du stöder ("Make the site available in English, Spanish and French") så registrerar den dem åt dig, med engelska som standard. Hämta sedan innehållet på besökarens språk.

På frontend löser mallens typade content-hooks upp lokaliserade fält åt dig — skicka med besökarens aktiva locale så returneras varje localized-fält som ett enda översatt värde:

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
}

Bakom kulisserna går CMS:et igenom en fallback-kedja — den begärda localen → dess konfigurerade fallbacks → standardlocalen — och rapporterar koden den faktiskt använde på varje post som localeResolved. Utelämna locale på enspråkiga sajter så returneras fält som råvärden.

Detta är rätt val när:

• Redaktörer som inte skriver kod behöver översätta innehåll
• Du vill att översättningar ska kunna versionshanteras
• Du behöver locale-specifik publicering (schemalagd publicering kommer snart — poster kräver för närvarande manuell publicering via API:t)

Se Innehållshantering för det fullständiga Content API.

Alternativ 2: Kodbaserat i18n-ramverk

För UI-strängar — etiketter, knappar, felmeddelanden, datum, valutor — be AI:n att koppla in ett i18n-ramverk direkt i ditt projekt:

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.

AI:n kommer att:

1. Välja ett ramverk — AI:n använder i18next med react-i18next (Proyectas standard)
2. Skapa katalogfiler i src/locales/ (en JSON per språk)
3. Omsluta text i t()-anrop (från react-i18next:s useTranslation-hook)
4. Lägga till en språkväljare som komponent
5. Koppla URL-routing med locale-prefix
6. Hantera RTL-layouter (dir="rtl") för arabiska, hebreiska m.fl.
7. Formatera siffror, datum och valutor enligt locale

Automatöversätt med AI:n

När ditt basspråk är på plats är AI:n utmärkt på att ta fram de övriga katalogfilerna:

• "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."

För känsligt innehåll (juridisk text, medicin, finans) bör en mänsklig översättare granska AI:ns output innan du publicerar.

Kombinera båda tillvägagångssätten

De flesta verkliga appar använder båda: kodbaserad i18n för UI-krom (knappar, felmeddelanden, navigering) och Content API för redaktionellt innehåll (artiklar, produktbeskrivningar). De samexisterar utan problem — ditt i18n-ramverk hanterar katalogfilerna vid byggtid, medan Content API levererar lokaliserade poster under körning.

Bästa praxis

1. Välj ditt basspråk och färdigställ texten först. Att översätta ett rörligt mål är en plåga.
2. Översätt i omgångar. Översätt inte löpande — vänta tills en funktion är stabil.
3. Testa RTL tidigt om du stöder arabiska eller hebreiska. RTL-buggar döljer sig tills du faktiskt tittar.
4. Inkludera lang och dir på <html>. Webbläsare och skärmläsare är beroende av det.
5. Använd Intl för formatering. Rulla inte egna datum- eller valutaformateringar — använd Intl.DateTimeFormat, Intl.NumberFormat.

Kommer snart

• Locale-hanteringsgränssnitt i builder — välj locales, se hur stor del av översättningarna som är klara och redigera kataloger utan att lämna Proyecta
• Automatöversättning vid sparande för nya strängar
• i18n-färdiga projektmallar med ramverket förkopplat