Planera en webbapp som hanterar översättningsarbetsflöden, lokaliseringsdata, granskningar, QA-kontroller och releaser. Inkluderar datamodell, UX och integrationer.
Lokalisering är det dagliga arbetet med att få produktens text (och ibland bilder, datum, valutor och formateringsregler) översatt, granskad, godkänd och levererad—utan att bygga går sönder eller användare blir förvirrade.
För ett produktteam är målet inte att "översätta allt". Målet är att varje språkversion ska vara korrekt, konsekvent och uppdaterad när produkten förändras.
De flesta team börjar med goda intentioner och slutar i oordning:
En användbar lokalisationshanteringswebbapp stödjer flera roller:
Du bygger en MVP som centraliserar strängar, spårar status per locale och stödjer grundläggande granskning och export. Ett fylligare system lägger till automation (synk, QA-kontroller), rikare kontext och verktyg som ordlista och translation memory.
Innan du designar tabeller eller skärmar, bestäm vad din lokalisationshanteringsapp faktiskt ansvarar för. Ett snävt scope gör första versionen användbar—och hindrar dig från att bygga om allt senare.
Översättningar lever sällan på ett och samma ställe. Skriv ner vad du behöver stödja från dag ett:
Den här listan hjälper dig undvika en "ett arbetsflöde för allt"-lösning. Till exempel kan marknadsföringstexter behöva godkännanden, medan UI-strängar behöver snabb iteration.
Välj 1–2 format för MVP:n, sedan kan du utöka. Vanliga alternativ är JSON, YAML, PO och CSV. Ett praktiskt MVP-val är JSON eller YAML (för app-strängar), plus CSV endast om ni redan förlitar er på kalkylbladsimporter.
Var tydlig med krav som pluralformer, nästlade nycklar och kommentarer. Dessa detaljer påverkar din hantering av lokalfiler och framtida import/export-pålitlighet.
Definiera ett källspråk (ofta en) och sätt fallback-beteende:
Bestäm också vad "klart" betyder per locale: 100% översatt, granskat eller skickat.
För MVP:n, fokusera på granskningsprocessen för översättningar och grundläggande i18n-arbetsflöde: skapa/redigera strängar, tilldela arbete, granska och exportera.
Planera senare tillägg—skärmdumpar/kontent, ordlista, translation memory-grunder och integrera maskinöversättning—men bygg inte dem förrän du validerat ditt kärnflöde med verkligt innehåll.
En översättningsapp lyckas eller misslyckas på sin datamodell. Om underliggande entiteter och fält är tydliga blir allt annat—UI, arbetsflöde, integrationer—enklare.
De flesta team täcker 80% av sina behov med en liten uppsättning tabeller/kollektioner:
en, en-GB, pt-BR).checkout.pay_button).Modellera relationerna explicit: ett Project har många Locales; en Key tillhör ett Project; en Translation tillhör en Key och en Locale.
Lägg till en status för varje translation så systemet kan guida människor:
draft → in_review → approvedblocked för strängar som inte bör släppas ännu (juridisk granskning, saknad kontext osv.)Spara statusändringar som events (eller i en historiktabell) så du senare kan svara på "vem godkände detta och när?".
Översättningar behöver mer än ren text. Fånga:
{name}, %d) och om de måste matcha källanSom minimum, spara: created_by, updated_by, tidsstämplar och en kort change_reason. Detta gör granskningar snabbare och skapar förtroende när team jämför vad som finns i appen med vad som skickades.
Lagringsbeslut formar allt: redigerings-UX, import/export-hastighet, diffing och hur säkert du kan skicka.
Rad-per-nyckel (en DB-rad per strängnyckel per locale) är utmärkt för dashboards och arbetsflöden. Du kan enkelt filtrera "saknas på franska" eller "behöver granskning", tilldela ägare och beräkna progress. Nackdelen: att rekonstruera en locale-fil för export kräver gruppering och ordning, och du behöver extra fält för filvägar och namespaces.
Dokument-per-fil (spara varje locale-fil som ett JSON/YAML-dokument) matchar tydligt hur repos fungerar. Det är snabbare att exportera och enklare att bibehålla exakt formatering. Men sökning och filtrering blir svårare om du inte också underhåller ett index av nycklar, statusar och metadata.
Många team använder en hybrid: lagra row-per-key som sanningskälla, plus genererade filsnapshots för export.
Behåll revisionshistorik på translation-enheten (key + locale). Varje ändring bör registrera: föregående värde, nytt värde, författare, tidsstämpel och kommentar. Detta gör granskningar och rollback enkla.
Separat, spåra release-snapshots: "vad levererades i v1.8". En snapshot kan vara en tagg som pekar på en konsekvent uppsättning godkända revisioner över lokaler. Detta hindrar sena redigeringar från att tysta ändra en levererad build.
Behandla inte "plural" som en enkel boolean. Använd ICU MessageFormat eller CLDR-kategorier (t.ex. one, few, many, other) så språk som polska eller arabiska inte tvingas in i engelska regler.
För genus och andra variationer, modellera dem som varianter av samma key (eller meddelande) istället för separata ad-hoc-nycklar, så översättare ser hela kontexten.
Implementera fulltextsökning över key, source text, translation och utvecklarnoteringar. Kombinera med filter som matchar verkligt arbete: status (nytt/översatt/granskat), tags, fil/namespace och saknas/tomt.
Indexera dessa fält tidigt—sökning är funktionen folk använder hundratals gånger om dagen.
En lokalisationshanteringswebbapp börjar ofta enkelt—ladda upp en fil, redigera strängar, ladda ner igen. Den blir komplicerad när du lägger till flera produkter, många lokaler, frekventa releaser och en stadig ström av automation (synk, QA, MT, granskningar).
Det enklaste sättet att hålla sig flexibel är att separera ansvar tidigt.
En vanlig, skalbar setup är API + web UI + bakgrundsjobb + databas:
Denna split hjälper dig lägga till fler workers för tunga uppgifter utan att skriva om hela appen.
Om du vill komma snabbare till en första fungerande version kan en plattform som Koder.ai hjälpa dig skissa web UI (React), API (Go) och PostgreSQL-schema från en strukturerad specifikation—sedan exportera källkoden när du är redo att ta över repo och deployment.
Håll API:t centrerat kring några kärnresurser:
checkout.button.pay).Designa endpoints så de stödjer både manuell redigering och automation. Till exempel bör listning av keys acceptera filter som "saknas i locale", "ändrad sedan" eller "behöver granskning".
Behandla automation som asynkront arbete. En kö hanterar typiskt:
Gör jobben idempotenta (säkra att köra om) och spara jobbloggar per projekt så team kan diagnosticera fel själva.
Även små team kan skapa stora dataset. Lägg till pagination för listor (keys, historik, jobb), cache för vanliga läsningar (projektets locale-statistik) och applicera rate limits för att skydda import/export-endpoints och publika tokens.
Dessa är tråkiga detaljer som förhindrar att systemet blir långsamt precis när adoptionen växer.
Om din app lagrar källsträngar och översättningshistorik är åtkomstkontroll inte valfritt—det är hur du förhindrar oavsiktliga ändringar och håller beslut spårbara.
En enkel uppsättning roller täcker de flesta team:
Behandla varje handling som en behörighet så du kan utveckla senare. Vanliga regler:
Detta matchar ett översättningshanteringssystem samtidigt som det är flexibelt för konsulter.
Om ert företag redan använder Google Workspace, Azure AD eller Okta så minskar SSO lösenordsrisk och gör offboarding omedelbar. E-post/lösenord kan fungera för små team—kräv då starka lösenord och återställningsflöden.
Använd säkra, kortlivade sessioner (HTTP-only cookies), CSRF-skydd, rate limiting och 2FA där möjligt.
Spara vem som ändrade vad och när: redigeringar, godkännanden, locale-ändringar, exports och behörighetsuppdateringar. Kombinera loggen med "undo" via versionshistorik så rollbacks är snabba och säkra (se /blog/plan-storage-and-versioning).
Ditt UI är där lokalisering faktiskt händer, så prioritera skärmar som minskar fram-och-tillbaka och gör status uppenbar vid en blick.
Starta med en dashboard som snabbt svarar tre frågor: vad är klart, vad saknas och vad är blockerat.
Visa progress per locale (procent översatt, procent granskat), plus en tydlig "saknade strängar"-räknare. Lägg till en review queue-widget som lyfter fram objekt som väntar på godkännande, och en "senast ändrat"-feed så granskare kan upptäcka riskfyllda ändringar.
Filter är viktigare än diagram: locale, produktområde, status, tilldelad och "ändrat sedan senaste release".
En bra editor är sida-vid-sida: källan till vänster, målet till höger, med kontext alltid synlig.
Kontext kan inkludera key, skärmdumps-text (om du har det), teckenbegränsningar och placeholders (t.ex. {name}, %d). Inkludera historik och kommentarer i samma vy så översättare slipper en separat diskussionsskärm.
Gör statusflödet till ett klick: Draft → In review → Approved.
Lokalisering är ofta "många små ändringar". Lägg till bulk-select med åtgärder som tilldela till användare/lag, ändra status och exportera/importera för en locale eller modul.
Håll bulk-åtgärder begränsade av roller (se /blog/roles-permissions-for-translators).
Tunga översättare lever i editorn i timmar. Stöd full tangentbordsnavigering, synliga fokusstater och genvägar som:
Stöd även skärmläsare och högkontrastläge—tillgänglighet ökar hastigheten för alla.
En lokalisationshanteringsapp lyckas eller misslyckas på arbetsflödet. Om folk inte kan se vad som ska översättas härnäst, vem som äger ett beslut eller varför en sträng är blockerad får du förseningar och ojämn kvalitet.
Börja med en tydlig arbetsenhet: en uppsättning keys för en locale i en specifik version. Låt projektledare (eller leads) tilldela arbete efter locale, fil/modul och prioritet, med ett valfritt slutdatum.
Gör tilldelningar synliga i en "My Work"-inkorg som svarar tre frågor: vad är tilldelat, vad är försenat och vad väntar på andra. För större team, lägg till arbetsbelastningssignaler (antal objekt, ordantal uppskattning, senaste aktivitet) så tilldelningar blir rättvisa.
Bygg ett enkelt statuspipline, t.ex: Untranslated → In progress → Ready for review → Approved.
Granskning bör vara mer än ett binärt val. Stöd inline kommentarer, föreslagna ändringar och approve/reject med motiv. När granskare avvisar, spara historiken—skriv inte över.
Detta gör din granskningsprocess reviderbar och minskar upprepade misstag.
Källtext kommer att ändras. När det händer, markera befintliga översättningar som Needs update och visa en diff eller "vad ändrades"-sammanfattning. Behåll den äldre översättningen som referens, men förhindra att den återgodkänns utan ett uttryckligt beslut.
Notera händelser som blockerar framsteg: ny tilldelning, granskning begärd, avslag, kommande förfallodatum och källändringar som påverkar godkända strängar.
Håll notiser handlingsbara med deep links som /projects/{id}/locales/{locale}/tasks så folk kan lösa problem med ett klick.
Manuell filhantering är där lokalisationsprojekt börjar spåra ur: översättare jobbar på föråldrade strängar, utvecklare glömmer att hämta uppdateringar och releaser skickas med halvfärdiga lokaler.
En bra lokalisationsapp behandlar import/export som en repeterbar pipeline, inte en engångsuppgift.
Stöd de vanliga vägar team faktiskt använder:
Vid export, tillåt filtrering på projekt, branch, locale och status (t.ex. "endast godkända"). Det förhindrar att delvis granskade strängar läcker in i produktion.
Synk fungerar bara om keys förblir konsekventa. Bestäm tidigt hur strängar genereras:
checkout.button.pay_now), skydda dem från oavsiktliga namnändringar.Din app bör upptäcka när en källsträng ändrats men key:n inte gjort det, och markera översättningar som needs review istället för att skriva över dem.
Lägg till webhooks så synk sker automatiskt:
main → importera uppdaterade källsträngar.Webhooks bör vara idempotenta (säkra att köra om) och producera tydliga loggar: vad ändrades, vad hoppades över och varför.
Om du implementerar detta, dokumentera den enklaste end-to-end-setupen (repo-access + webhook + PR-export) och visa det i UI:t, t.ex. /docs/integrations.
Lokaliserings-QA är där en översättningshanteringsapp slutar vara en enkel editor och börjar förhindra produktionsbuggar.
Målet är att fånga problem innan strängar skickas—särskilt de som bara syns i ett specifikt locale-fil.
Börja med kontroller som kan bryta UI eller krascha formatering:
{count} finns i engelskan men saknas i franskan, eller pluralformer inkonsekventa).% i printf-stil, felaktiga ICU-meddelanden).Behandla dessa som "blockera release" som standard, med ett tydligt felmeddelande och en pekare till exakt key och locale.
Dessa behöver inte alltid bryta appen, men försämrar kvalitet och varumärkes-konsistens:
Text kan vara korrekt och ändå se konstigt ut. Lägg till ett sätt att begära skärmdumpskontext per key (eller bifoga en skärmdump till en key), så granskare kan validera trunkering, radbrytningar och ton i verkligt UI.
Innan varje release, generera en QA-sammanfattning per locale: fel, varningar, oöversatta strängar och värsta syndarna.
Gör det enkelt att exportera eller länka internt (t.ex. /releases/123/qa) så team har en enda "go/no-go"-vy.
Att lägga till en ordlista, translation memory (TM) och maskinöversättning (MT) kan kraftigt snabba upp lokalisering—men bara om appen behandlar dem som vägledning och automation, inte som "publiceringsklart" innehåll.
En ordlista är en kuraterad lista med termer och godkända översättningar per locale (produktnamn, UI-begrepp, juridiska fraser).
Spara poster som term + locale + godkänd översättning + noteringar + status.
För att upprätthålla den, lägg in kontroller i redigeringsvyn:
TM återanvänder tidigare godkända översättningar. Håll det enkelt:
Behandla TM som ett förslagssystem: användare kan acceptera, redigera eller avvisa träffar, och endast accepterade översättningar ska matas tillbaka till TM.
MT är användbart för utkast och backloggar, men det bör inte vara standard slutligt innehåll.
Gör MT opt-in per projekt och per jobb, och låt MT-fyllda strängar gå genom normalt granskningsflöde.
Olika team har olika begränsningar. Tillåt admin att välja leverantörer (eller inaktivera MT helt), sätta användningsgränser och välja vilken data som skickas (t.ex. exkludera känsliga keys).
Logga förfrågningar för kostnadsinsyn och revision, och dokumentera alternativ i /settings/integrations.
En lokalisationsapp bör inte bara "lagra översättningar"—den bör hjälpa dig skicka dem säkert.
Nyckelidé är en release: en fryst snapshot av godkända strängar för en specifik build, så vad som deployas är förutsägbart och reproducerbart.
Behandla en release som ett oföränderligt paket:
Detta låter dig svara: "Vad skickade vi i v2.8.1 för fr-FR?" utan gissningar.
De flesta team vill validera översättningar innan användare ser dem. Modellera exporter per miljö:
Gör export-endpoint explicit (t.ex. /api/exports/production?release=123) för att förhindra oavsiktliga läckor av icke-granskad text.
Rollback är enklast när releaser är oföränderliga. Om en release introducerar problem (brutna placeholders, fel terminologi) ska du kunna:
Undvik att "redigera produktion i stunden"—det bryter audit trails och gör incidenter svårare att analysera.
Noterbart: detta "snapshot + rollback"-tänk passar väl med hur moderna build-plattformar fungerar. Till exempel inkluderar Koder.ai snapshots och rollback som ett förstaklass-flöde för applikationer du genererar och hostar, vilket är en användbar mental modell när du designar oföränderliga lokalisationsreleaser.
Efter deployment, kör en enkel operativ checklista:
Om du visar releashistorik i UI:t, inkludera en enkel "diff vs tidigare release"-vy så team snabbt kan upptäcka riskfyllda ändringar.
Säkerhet och insyn är skillnaden mellan ett användbart lokalisationsverktyg och ett team kan lita på. När arbetsflödet rullar, lås ner det och börja mäta.
Följ principen minst privilegium som standard: översättare bör inte kunna ändra projektinställningar, och granskare bör inte ha tillgång till fakturering eller admin-specifika exporter. Gör roller explicita och reviderbara.
Spara hemligheter säkert. Håll databasuppgifter, webhook-signeringsnycklar och tredjepartstokens i en secrets manager eller krypterade miljövariabler—aldrig i repot. Rotera nycklar regelbundet och när någon slutar.
Backups är inte valfritt. Ta automatiserade backups av databas och objektlagring (lokalfiler, bilagor), testa återställningar och definiera retention. En "backup som inte går att återställa" är bara extra lagring.
Om strängar kan innehålla användarinnehåll (supportärenden, namn, adresser), undvik att lagra det i översättningssystemet. Föredra placeholders eller referenser, och rensa loggar från känsliga värden.
Om du måste bearbeta sådan text, definiera retention-regler och åtkomstbegränsningar.
Sätt upp några mätvärden som speglar arbetsflödets hälsa:
En enkel dashboard plus CSV-export räcker för att börja.
När grunden är stabil, överväg:
Om du planerar att erbjuda detta som en produkt, lägg till en tydlig uppgraderingstrappa och call-to-action (se /pricing).
Om ditt omedelbara mål är att snabbt validera arbetsflödet med verkliga användare, kan du också prototypa MVP:n på Koder.ai: beskriv roller, statusflöde och import/export-format i planeringsläge, iterera på React-UI och Go-API via chatt, och exportera kodbasen när du är redo att hårdgöra för produktion.
En lokalisationshanteringswebbapp centraliserar dina strängar och hanterar arbetsflödet runt dem — översättning, granskning, godkännanden och export — så att team kan skicka uppdateringar utan trasiga nycklar, saknade placeholders eller otydlig status.
Börja med att definiera:
pt-BR → pt → en)En snäv scope förhindrar att du försöker med ett "en storlek passar alla"-arbetsflöde och håller MVP:n användbar.
De flesta team täcker kärnflödet med:
Spara metadata som förhindrar produktionsbuggar och onödiga granskningar:
Det beror på vad du optimerar för:
En vanlig approach är hybrid: row-per-key som sanningskälla, plus genererade snapshot-filer för export.
Använd två lager:
Detta förhindrar att "tysta ändringar" modifierar redan skickat material och gör incidenter enklare att felsöka.
Börja med roller som matchar verkligt arbete:
Håll API:t centrerat på några resurser:
Projects, Locales, Keys, TranslationsGör list-endpoints filterbara för verkliga uppgifter, t.ex.:
Kör långsamt arbete asynkront:
Gör jobben idempotenta (säkra att köra om) och spara loggar per projekt så team kan felsöka utan att rota i serverloggar.
Prioritera kontroller som förebygger trasigt UI:
{count}, %d) och plural-täckningBehandla dessa som release-blocker som standard, och lägg till mjukare varningar för ordlista-konsistens och whitespace/casing så team kan förbättra kvalitet utan att blockera allt.
draft → in_review → approved)När dessa entiteter är tydliga blir UI, behörigheter och integrationer mycket enklare att bygga och underhålla.
created_by, updated_by, tidsstämplar, ändringsorsak)Detta är skillnaden mellan "en texteditor" och ett system team kan lita på.
Definiera behörigheter per handling (redigera källor, godkänna, exportera, hantera lokaler) så du kan utveckla systemet utan att bryta arbetsflöden.
Detta stöder både manuell redigering i UI och automation via CLI/CI.