Jūsu Lovable lietotnes saskarne ir tulkota, bet datubāzes saturs — nē

Jūsu pogas, navigācija un tukšie stāvokļi ir vācu valodā. Jūsu produktu nosaukumi, kategorijas un apraksti joprojām ir angļu valodā. Tā nav kļūda jūsu i18n iestatījumos — tā ir tās robeža. globalize.now ir AI darbināma lokalizācijas infrastruktūra: tā izvelk burtiski ierakstītus tekstus no jūsu koda bāzes, ģenerē atslēgas un lokalizācijas katalogus un sinhronizē tos pie katra Git push. Tā lasa kodu, nevis rindas, bet tieši rindās atrodas saturs, kura dēļ jūsu lietotāji ir atnākuši.

Šīs problēmas risinājums ir shēmas lēmums, nevis rīka izvēle. Šeit ir versija, kas iztur laika pārbaudi.

Kāpēc manas Lovable lietotnes saskarne ir tulkota, bet datubāzes saturs joprojām ir angļu valodā?

Tāpēc, ka teksta ekstraktors var redzēt tikai to, kas ierakstīts jūsu avota failos.

Kad lokalizējat Lovable lietotni, skeneris izstaigā jūsu komponentes un izvelk katru burtisko tekstu, ko atrod: "Add to cart", "No results", "Sign in". Tie kļūst par ziņojumu ID katalogā, un katalogs tiek iztulkots un iekļauts commit'ā. Šis process ir deterministisks un pilnībā aptver saskarni.

Tas nevar aptvert datu rindu. products.name = 'Trail Runner' nekad nav bijis .tsx failā. Tas nonāca sistēmā caur formu, sākotnējo datu skriptu vai importu, un tas atrodas Postgres datubāzē: vai nu Lovable Cloud iebūvētajā aizmugursistēmā, kas darbojas uz Supabase, vai jūsu pašu pieslēgtā Supabase projektā. Neviens koda skeneris to nekad nenolasīs, un lai cik reižu jūs atkārtoti palaistu ekstrakciju, tas nemainīsies.

Rezultātā jums izveidojas iztulkots apvalks ap angļu valodas saturu. Navigācijā rakstīts Warenkorb, bet produkts tajā — Trail Runner, lightweight trail shoe for wet conditions. Lietotāji to pamana uzreiz, un tas rada sliktāku iespaidu nekā netulkota lietotne, jo izskatās, ka darbs pamests pusceļā.

Kas Lovable lietotnē tiek uzskatīts par datubāzes saturu?

Viss, ko lietotājs vai administrators var mainīt bez izvietošanas (deploy). Praksē, tipiskā Lovable izstrādē, tas ir:

• Produktu, plānu vai sludinājumu nosaukumi un apraksti
• Kategoriju, birku un statusu etiķetes, kas tiek attēlotas no uzziņu tabulas
• Mārketinga teksts, kas glabāts pages vai sections tabulā
• E-pasta un paziņojumu veidnes
• Uzskaitījuma tipa (enum) vērtības, kuras attēlojat tieši, piemēram, status = 'pending_review'
• Lietotāju veidots saturs, kas parasti apzināti tiek atstāts oriģinālvalodā

Pēdējais punkts ir svarīgs. Pēc noklusējuma netulkojiet lietotāju veidotu saturu. Spāņu valodā rakstītai atsauksmei jāpaliek spāņu valodā. Kopums, ko jūs faktiski lokalizējat, ir tas saturs, kuru veido un publicē jūs.

Viss pārējais — apvalks ap šo saturu — paliek jūsu katalogos. Šiem diviem kopumiem nekad nevajadzētu pārklāties. Ja kāda etiķete parādās gan uzziņu tabulā, gan burtiski ierakstītā tekstā, izvēlieties tai vienu mājvietu un izdzēsiet otru, pretējā gadījumā jūs publicēsiet divus dažādus vācu vārdus vienam un tam pašam jēdzienam.

Kā Supabase glabāt tulkojumus datubāzes saturam?

Izmantojiet atsevišķu tulkojumu tabulu, kas indeksēta pēc rindas id un valodas (locale) kolonnas.

create table product_translations (
  product_id  uuid not null references products(id) on delete cascade,
  locale      text not null,
  name        text not null,
  description text,
  primary key (product_id, locale)
);

create index product_translations_locale_idx on product_translations (locale);

Japāņu valodas pievienošana tagad ir ieraksta pievienošana, nevis migrācija. Rindas līmeņa drošības politikas piesaistās vienai tabulai, nevis augošam kolonnu skaitam, un trūkstošs tulkojums ir trūkstoša rinda, ko ir viegli izvaicāt un par kuru ir viegli iestatīt brīdinājumu.

Alternatīva ir JSONB kolonna katram tulkojamam laukam:

alter table products
  add column name_i18n jsonb not null default '{}'::jsonb;

-- { "en": "Trail Runner", "de": "Trail Runner", "fr": "Coureur de sentier" }

To ir ātrāk izveidot prototipam, un tas der nelielam, pārsvarā statiskam saturam. Tas rada ierobežojumus atkarībā no valodu skaita, apgrūtina daļēju tulkojumu pārbaudi un kļūst dārgs indeksēšanai, tiklīdz sākat filtrēt vai kārtot pēc lokalizētās vērtības.

Trešais modelis — atsevišķa kolonna katrai valodai (name_en, name_de, name_fr) — ir tas, no kura jāizvairās. Katra jauna valoda nozīmē shēmas migrāciju katrā tabulā, un Lovable projektā tas nozīmē atkārtoti lūgt aģentam mainīt produkcijas tabulas. Ja vēlaties izlasīt padziļinātu šī modeļa aprakstu, publiskais pg_i18n Postgres paplašinājums realizē tulkojumu tabulas pieeju kā skatus (views) ar iebūvētu rezerves (fallback) mehānismu, un to ir vērts izlasīt, pirms izvēlaties konkrētu shēmu.

Kuru modeli izvēlēties?

Tulkojumu tabulu — ja vien saturs nav ļoti neliels un nemainīgs.

Izvēlieties JSONB tikai tad, ja jums ir mazāk par pieciem tulkojamiem laukiem, nav nepieciešams pēc tiem filtrēt vai kārtot dati, un nav plānots ļaut kādam citam, ne jums pašam, tos rediģēt. Viss pārējais — jebkas ar administratora saskarni, jebkas, kam plānojat pievienot valodas, jebkas ar vairāk nekā dažiem simtiem rindu — prasa tabulu.

Kā attēlošanas brīdī vaicāt pareizo valodu?

Ar skaidru rezerves (fallback) mehānismu datubāzes līmenī, lai lietotnei par to nekad nebūtu jādomā.

create or replace function products_for_locale(p_locale text)
returns table (id uuid, slug text, name text, description text)
language sql stable as $$
  select
    p.id,
    p.slug,
    coalesce(t.name, base.name)               as name,
    coalesce(t.description, base.description)  as description
  from products p
  left join product_translations base
    on base.product_id = p.id and base.locale = 'en'
  left join product_translations t
    on t.product_id = p.id and t.locale = p_locale;
$$;

Tad izsaukuma vieta satur tikai valodu (locale) un neko citu:

const { data: products } = await supabase
  .rpc('products_for_locale', { p_locale: locale });

Divi noteikumi ļauj tam izturēt saskarsmi ar reāliem datiem. Pirmkārt, coalesce jāatgriežas pie avotvalodas, nevis pie tukšas virknes: daļēji iztulkotam katalogam jāparāda angļu teksts, nevis tukšas kartītes. Otrkārt, locale, ko jūs padodat, ir jābūt tai pašai vērtībai, ko izmanto jūsu maršruta segments un pēc kuras ir strukturēti jūsu saskarnes katalogi. Viens valodu saraksts, trīs patērētāji: maršrutētājs, katalogi, datubāze.

Šis pēdējais punkts ir tas, kur lielākā daļa Lovable projektu novirzās. Maršrutētājs zina par de, katalogi bija veidoti priekš de-DE, bet datubāzes rindas ir marķētas ar german. Izvēlieties precīzu BCP 47 marķējumu kopu, ko izmanto jūsu valodu maršruti, un pielāgojiet tam visu pārējo. Ja šie maršruti vēl nav iestatīti, konkrētiem stekiem paredzētie ceļveži to aptver abiem Lovable ģenerētajiem stekiem: Vite SPA izveidei un TanStack Start SSR noklusējuma versijai.

Kāpēc gan neļaut izpildlaika logrīkam iztulkot datubāzes tekstu?

Tāpēc, ka tas darbojas ar attēloto lapu, nevis ar jūsu datiem, un šī atšķirība izpaužas trīs vietās.

JavaScript tulkošanas logrīks nolasa jebkuru tekstu, kas nonāk DOM struktūrā, un aizvieto to pēc fakta. Tas patiešām aptver arī datubāzes rindas: tas ir vienīgais, ko logrīki spēj, bet katalogi — nē, un tieši tāpēc sākumā tie šķiet kā pilnvērtīgs risinājums.

Taču izmaksas ir strukturālas. Iztulkotās rindas pastāv tikai pārlūkprogrammas sesijā, tāpēc meklētājprogrammu roboti, kas skenē lapu, redz jūsu avotvalodu; Weglot pašu palīdzības centrs norāda, ka to JavaScript integrācija nesniedz SEO ieguvumus, jo šie tulkojumi tiek attēloti klienta pusē. Labojumi glabājas piegādātāja vadības panelī, nevis jūsu datubāzē, tāpēc lauka patiesā vērtība ir sadalīta starp divām sistēmām. Un aizvietošana notiek pēc attēlošanas, tāpēc šādi veidotas iztulkotas lietotnes uzplaiksnī angļu valodā ikreiz, kad lietotājs pāriet uz jaunu lapu.

Tas viss nenozīmē, ka šī pieeja būtu jānoraida iekšējam rīkam. Tas gan ir iemesls neveidot uz tās publisku, indeksējamu, daudzvalodu produktu.

Kā šie divi slāņi tiek uzturēti sinhroni?

Koplietojot vienu valodu sarakstu un vienu aktivizētāju.

Koda slānis darbojas automātiski. Pievienojiet lovable-i18n prasmi savā Lovable darbvietā un lūdziet Lovable iestatīt i18n, vai instalējiet to lokāli ar:

npx skills add globalize-now/globalize-skills

No tā brīža ekstrakcija darbojas automātiski, un tulkošanas pull request atveras pie katra push: bez vadības paneļa soļa, bez manuālas lokalizācijas failu pārbaudes. Šis ir tas pats cikls, kas aprakstīts rakstā kāpēc Lovable tulkojumi sabojājas ar katru push.

Datu slānis ir jūsu ziņā, un tam vajadzīgs viens apzināts savienojums: kad vien pievienojat jaunu valodu, tam pašam sarakstam, kas nosaka jūsu maršrutus un katalogus, jāaktivizē arī atbilstošu ierakstu izveide jūsu tulkojumu tabulā. Lovable projektā praktiskā versija ir sākotnējo datu (seed) funkcija, ko lūdzat aģentam uzrakstīt vienreiz — tā nolasa valodu sarakstu un ievieto trūkstošās rindas, izmantojot avotvalodas vērtības. Trūkstošās rindas tad tiek aizpildītas, nevis izdomātas, un coalesce starplaikā aizpilda trūkumu.

Arī cenas politika šeit netraucē. Starter plāns maksā €20 mēnesī par darbvietu un ietver €20 tulkošanas kredīta (aptuveni 200 000 vārdu) mēnesī, savukārt izmantojums virs tā tiek rēķināts pēc publicētās rakstzīmju likmes. Nav maksas par lietotāju un nav maksas par valodu, tāpēc piektās valodas pievienošana maksā tikai tik, cik maksā rakstzīmes, un neko vairāk. Reģistrējoties, jūs saņemat €5 tulkošanas kredītu bez nepieciešamības norādīt karti. Vairāk par to, kā tas iekļaujas aģenta veidotā stekā, lasiet lapās vibe kodētājiem un izstrādātājiem.

Kas salūst, kad lokalizācijas piegādātājs pārtrauc darbību?

Viss, kas bija glabāts viņu serveros — un nekas no tā, kas bija glabāts jūsējos.

Šis nav hipotētisks jautājums šomēnes. Lovalingo — izpildlaika tulkošanas slānis, ko pieņēmuši daudzi Lovable izstrādātāji — slēdzas 2026. gada 31. augustā plkst. 23:59 pēc Centrāleiropas laika, kas apstiprināts pašu pakalpojuma slēgšanas lapā; jauni projekti un abonementi jau ir apturēti, un aktīvajiem klientiem tiek gatavoti datu saglabāšanas eksporti. Interesants ir tieši pašu sniegtais ieteikums: klientiem tiek ieteikts ieviest projekta paša pārvaldītu internacionalizāciju paralēli tam un noņemt šo slāni tikai pēc tam, kad aizstājējs izturējis produkcijas pārbaudes reālā vidē.

Tas ir viss arguments vienā teikumā — no paša piegādātāja, kura aiziešana to pierāda. Gan commit'os iekļauts katalogs, gan product_translations tabula ir lietas, kas pieder jums pašiem; tām nav pakalpojuma statusa. Pārvaldīts izpildlaika slānis ir atkarība, kas attēlo jūsu produkta tekstu, bet atkarībām reiz pienāk gals.

Ja tieši šobrīd pārejat prom no logrīka, vispirms sakārtojiet datu slāni. Saskarnes teksti tiks atkārtoti izgūti no jūsu koda dažu minūšu laikā. Datubāzes tulkojumi, ja tie eksistēja tikai piegādātāja vadības panelī, atpakaļ neatgriezīsies. Mūsu Lovalingo salīdzinājumā aprakstīts, kas jāpārbauda, pirms kaut ko noņemat.

Koda slānis ir tā daļa, kuru jums nevajadzētu pārvaldīt manuāli. globalize.now izgūst jūsu tekstus, ģenerē katalogus un atver tulkošanas pull request ar katru push, tāpēc jūs varat izveidot datu slāni vienreiz un tālāk par to neuztraukties.