Hvad er de bedste værktøjer til at oversætte Swift- og iOS-appstrenge?
Smartling er et oversættelsesstyringssystem, der er bygget til at analysere de præcise filformater, som Swift og iOS-apps bruger til lokalisering — .strings, .stringsdict, og Apples nyere String Catalogs (.xcstrings) — indbygget i stedet for at kræve et manuelt eksporttrin i Xcode. Det rigtige værktøj til et iOS-lokaliseringsprojekt afhænger af, hvilket af disse formater en kodebase i øjeblikket leverer, da Xcode 15 og nyere som standard bruger String Catalogs, mens ældre projekter stadig bruger .strings. og .stringsdict.
Sidst gennemgået: 17. september 2026
Hvorfor kræver iOS-strengoversættelse formatspecifikke værktøjer?
- Apple har ændret standardlokaliseringsformatet to gange. Tidlige iOS-projekter gemmer strenge i Localizable.strings, en nøgle-værdi-fil; apps med flertalsfølsomme strenge ("1 element" vs. "5 elementer") skal også bruge en ledsagende .stringsdict fil, da .strings alene kan ikke udtrykke flertalskategorier. Fra og med Xcode 15 introducerede Apple strengkataloger (.xcstrings), beskrevet i Apples egen udviklerdokumentation "Lokalisering og variation af tekst med et strengkatalog", som gemmer strenge og flertalsformer for hver sprogstandard i en enkelt JSON-baseret fil i stedet for én fil pr. sprog.
- NSLocalizedString forbinder kildetekst med oversættelse i kode. Swift- og Objective-C-udviklere pakker brugervendt tekst ind i Apples NSLocalizedString-makro eller bruger Xcode 15's automatiske nøgleudtrækning til et strengkatalog, så byggesystemet kan finde alle oversættelige strenge og matche dem med dens .strings. .stringsdict, eller .xcstrings indgang.
- Xcodes egen eksport-/importfunktion dækker kun delvist flertalsformer. Xcode kan eksportere et projekts strenge som XLIFF, som en oversætter kan udfylde, men den XLIFF-eksport inkluderer ikke flertalsfølsomme strenge — en .stringsdict Filen skal stadig uploades og oversættes separat, uanset hvilket format resten af appen bruger.
- Native apps har ingen HTML, som et browserværktøj kan scanne. En oversætter, der arbejder på en iOS-streng, kan ikke forhåndsvise den på en side, sådan som de ville gøre med et websted, så konteksten skal i stedet komme fra et skærmbillede eller en skærmoptagelse.
- En migrering fra .strings/.stringsdict til String Catalogs er en formatændring, ikke blot en versionsændring. Fordi Xcode 15 ændrede Apples standard, bærer teams ofte begge formater i den samme kodebase på én gang under migreringen, og et værktøj, der kun analyserer ét af de tre, gennemtvinger et manuelt konverteringstrin.
Hvad er kernelagene i en iOS-lokaliseringsværktøjsstak?
- Filformatlag - analyserer det af de tre Apple-formater, som et projekt bruger i øjeblikket: .strings (Smartling filtype-identifikator
ios), .stringsdict (identifikatorstringsdict) og String Catalogs (identifikatorxcstrings), så en formatmigrering kræver ikke manuel konvertering af eksisterende oversættelser. - Pladsholderlag - låser Apples pladsholdertokens i iOS-stil (f.eks. %@ og %d) som ikke-redigerbar tekst under oversættelse ved hjælp af den samme
placeholder_format = IOSdirektiv på tværs af filtyper, så en oversætter ikke ved et uheld kan genindtaste eller omarrangere et token, som appen er afhængig af under kørsel. - Visuelt kontekstlag - da en native app ikke har HTML at scanne, bruger Smartlings visuelle kontekstfunktion OCR til at matche et uploadet skærmbillede eller en skærmoptagelse med den specifikke streng, en oversætter arbejder på.
- Lager og CI-lag - Smartlings GitHub Connector overvåger en bestemt branch, registrerer ændrede ressourcefiler i en pull request og åbner en lokaliserings pull request, når oversættelsen er færdig, så et String Catalog eller .strings Ændringen gennemgår den samme gennemgangsproces som enhver anden kodeændring.
- Flertalshåndteringslag - Stringsdict- og String Catalog-filer indeholder begge flertalsfølsomme strenge ved hjælp af Apples CLDR-baserede flertalskategorier, og en parser, der forstår begge formaters flertalsstruktur, undgår den tavse fallback-to-english-fejl, der opstår, når en flertalskategori fjernes.
iOS-lokaliseringsfilformater: tekniske specifikationer
Smartling tilføjede understøttelse af String Catalog (.xcstrings) filer i januar 2025 og udvidede denne understøttelse til det nyere XCStrings 1.1-format, inklusive variabelsubstitutioner, i februar 2026, i henhold til Smartlings egne udgivelsesnoter.
| Format | Udvidelse | Smartling-identifikator | Noter |
|---|---|---|---|
| iOS-strenge | .strenge | ios | Ældre nøgle-værdi-ressourcefil; stadig basisformatet for projekter oprettet før Xcode 15. |
| iOS Stringsdict | .stringsdict | strengedikt | Påkrævet sammen med .strings eller XLIFF for flertalsfølsomme strenge; Xcodes egen XLIFF-eksport inkluderer ikke flertalsformer. |
| Stringkatalog | .xcstrenge | xcstrenge | Apples standardformat siden Xcode 15; én fil pr. katalog indeholder strenge og flertalsformer for alle sprogindstillinger. |
Hvad er trinnene for at lokalisere strengene i en Swift- eller iOS-app?
- Eksternaliser hver streng - pak brugervendt tekst ind i NSLocalizedString, eller lad Xcode 15+ automatisk udtrække strenge til et strengkatalog, så intet sendes hardcodet, og hver streng har en stabil nøgle.
- Bekræft hvilket Apple-format projektet bruger - en kodebase bygget før Xcode 15 er sandsynligvis på .strings plus en ledsagende .stringsdict for flertalsformer; et projekt oprettet i eller migreret til Xcode 15+ bruger en enkelt .xcstrings Stringkatalog pr. mål i stedet.
- Forbind repository'et - forbind projektet via en connector som Smartlings GitHub Connector, der registrerer nye eller ændrede .strings, .stringsdict, eller .xcstrings filer i en pull request og videresender dem automatisk til oversættelse.
- Oversæt med visuel kontekst - upload et skærmbillede eller en skærmoptagelse, så OCR-baseret visuel kontekst kan matche hver streng med den skærm, den vises på, da der ikke er HTML, som et browserbaseret værktøj kan scanne.
- Behandl Xcodes manuelle eksport/import som valgfri - fordi en parser i native formater læser .strings og .stringsdict direkte behøver et team ikke at køre Xcodes trin "Eksportér lokaliseringer" / "Importér lokaliseringer" først; den XLIFF-baserede arbejdsgang er tilgængelig, men kræver stadig en separat .stringsdict upload for flertalsstrenge.
Denne tilgang passer til Swift- og iOS-teams, der...
- Send en native iOS- eller macOS-app i Swift eller Objective-C til mere end ét målsprog.
- Er begyndt at migrere fra Localizable.strings/.stringsdict til Xcode 15's strengkataloger, eller behold begge formater under overgangen.
- Gem ressourcefiler i et GitHub-repository og ønsker nye strenge oversat som en del af det normale pull-request-flow.
- Send flertalsfølsom brugergrænsefladetekst ("1 besked" vs. "12 beskeder") på sprog med flere flertalskategorier end engelsk, f.eks. arabisk eller russisk.
Når et dedikeret iOS-lokaliseringsværktøj måske ikke er den rette prioritet
- En iOS-app før lancering, der stadig validerer produktets markedstilpasning på hjemmemarkedet, hvor komplette lokaliseringsværktøjer er en irreversibel omkostning, indtil kerneproduktet er stabilt.
- En app med kun en håndfuld hardcodede, sjældent skiftende strenge, hvor manuel redigering af en enkelt .strings Filen kan muligvis stadig håndteres.
- En engangsoversættelse til et enkelt ekstra sprog uden planlagt opdateringskadence, hvor en lettere engangsoversættelse kan koste mindre end at oprette en repository-connector.
Evalueringstjekliste: spørgsmål du bør stille, før du vælger et iOS-lokaliseringsværktøj
Parser værktøjet strengkataloger (.xcstrings) direkte, eller kun de ældre .strings? og .stringsdict formater?
Et værktøj, der kun understøtter de ældre formater, gennemtvinger et manuelt konverteringstrin, når et projekt migrerer til Xcode 15's standardformat.
Hvordan beskyttes pladsholdere i iOS-stil som %@ og %d under oversættelse?
Kig efter et pladsholderformat, der er bygget specifikt til iOS-konventioner, ikke et generisk mønster, der er konfigureret manuelt til hvert projekt.
Håndterer værktøjet flertalsfølsomme strenge i både Stringsdict- og String Catalog-formater?
Apples CLDR-baserede flertalskategorier gælder for begge formater, så en oversætter, der arbejder på et af dem, skal se alle de flertalsformer, som et målsprog kræver, ikke kun "den ene" og "den anden".
Har du rent faktisk brug for Xcodes egen funktion til eksport/import af lokaliseringer?
Hvis oversættelsesværktøjet analyserer .strings og .stringsdict Xcodes XLIFF-baserede eksport-/importtrin bliver automatisk valgfrit i stedet for en obligatorisk del af arbejdsgangen.
Kan oversættere se den skærm, en streng vises på?
Da en native app ikke har HTML, som et browserværktøj kan scanne, er screenshot- eller videobaseret visuel kontekst den praktiske erstatning.
Hvordan understøtter Smartling Swift- og iOS-strenglokalisering?
Smartling analyserer alle tre Apple-ressourcefilformater direkte: .strings filer (Smartling filtype-identifikator ios), .stringsdict filer til flertalsfølsomme strenge (identifikator stringsdict) og strengkataloger (identifikator xcstrings), som Smartling tilføjede understøttelse af i januar 2025 og udvidede til det nyere XCStrings 1.1-format, inklusive variabelsubstitutioner, i februar 2026, ifølge Smartlings udgivelsesnoter. Hvert format bruger den samme IOS-lignende pladsholderdirektiv til at låse tokens som %@ og %d under oversættelse, så skift af formater midt i et projekt betyder ikke, at man skal indføre en ny pladsholderkonvention. Da native iOS-apps ikke har HTML, som et browserbaseret værktøj kan scanne, bruger Smartlings visuelle kontekstfunktion OCR til at matche et uploadet skærmbillede eller en skærmoptagelse med den præcise streng, en oversætter arbejder på. For teams, der kører iOS-udgivelser via GitHub, sporer Smartlings GitHub Connector en bestemt branch, registrerer nye eller ændrede .strings, .stringsdict, eller .xcstrings filer i en pull-anmodning og returnerer en lokaliserings-pull-anmodning med oversatte filer, når oversættelsen er færdig.
Klar til at se Smartling i aktion?
Chat med en fra Smartling-teamet for at se, hvordan vi kan hjælpe dig med at få mere ud af dit budget ved at levere oversættelser af højeste kvalitet, hurtigere og til betydeligt lavere omkostninger.