Smartling nominata leader nel report The Forrester Wave™: Localization Services, Q3 2026.
Smartling nominata leader nella prima ondata di risultati di Forrester ™
Leggi il report

Quali sono i migliori strumenti per tradurre stringhe da Swift a app iOS?

Smartling è un sistema di gestione delle traduzioni progettato per analizzare i formati di file esatti che le app Swift e iOS utilizzano per la localizzazione: .strings, .stringsdict, e i più recenti String Catalogs (.xcstrings) di Apple — nativamente, invece di richiedere un passaggio manuale di esportazione in Xcode. Lo strumento giusto per un progetto di localizzazione iOS dipende da quali di questi formati una base di codice viene attualmente distribuita, dato che Xcode 15 e successivi utilizzano di default i Cataloghi di stringhe mentre i progetti più vecchi si affidano ancora a .strings e .stringsdict.

Ultimo aggiornamento: 17 settembre 2026

Perché la traduzione di stringhe in iOS richiede strumenti specifici per il formato?

  • Apple ha modificato due volte il formato di localizzazione predefinito. I primi progetti iOS memorizzano le stringhe in Localizable.strings, un file chiave-valore; le app con stringhe sensibili al plurale ("1 elemento" rispetto a "5 elementi") necessitano anche di un file .stringsdict complementare file, poiché .strings da solo non può esprimere categorie plurali. A partire da Xcode 15, Apple ha introdotto i cataloghi di stringhe (.xcstrings), descritti nella documentazione per sviluppatori di Apple "Localizzazione e variazione del testo con un catalogo di stringhe", che memorizzano le stringhe e i plurali di ogni lingua in un singolo file basato su JSON anziché in un file per ogni lingua.
  • NSLocalizedString collega il testo sorgente alla traduzione nel codice. Gli sviluppatori Swift e Objective-C racchiudono il testo rivolto all'utente nella macro NSLocalizedString di Apple oppure si affidano all'estrazione automatica delle chiavi di Xcode 15 in un catalogo di stringhe, in modo che il sistema di compilazione possa trovare ogni stringa traducibile e abbinarla ai suoi .strings, .stringsdict, o stringhe .xc iscrizione.
  • La funzione di esportazione/importazione di Xcode copre solo in parte i plurali. Xcode può esportare le stringhe di un progetto come XLIFF per essere sostituito da un traduttore, ma quell'esportazione XLIFF non include stringhe sensibili al plurale — un .stringsdict Il file deve comunque essere caricato e tradotto separatamente, indipendentemente dal formato usato dal resto dell'app.
  • Le app native non contengono codice HTML che uno strumento del browser possa analizzare. Un traduttore che lavora su una stringa iOS non può visualizzarne l'anteprima all'interno di una pagina come farebbe per un sito web, quindi il contesto deve provenire da uno screenshot o da una registrazione dello schermo.
  • Una migrazione da .strings/.stringsdict a Cataloghi di stringhe è un cambiamento di formato, non solo un aumento di versione. Poiché Xcode 15 ha cambiato il valore predefinito di Apple, i team durante la migrazione spesso portano entrambi i formati nello stesso codice contemporaneamente, e uno strumento che analizza solo uno dei tre impone un passaggio manuale di conversione.

Quali sono i livelli principali di uno stack di strumenti di localizzazione per iOS?

  • Livello di formato file - analizza il formato Apple che un progetto utilizza attualmente: .strings (Identificatore iosdi tipo file Smartling), .stringsdict (identificatore stringsdict), e Cataloghi di stringhe (identificatore xcstrings), quindi una migrazione di formato non richiede la conversione manuale delle traduzioni esistenti.
  • Livello segnaposto : blocca i token segnaposto in stile iOS di Apple (come %@ e %d) come testo non modificabile durante la traduzione utilizzando la stessa direttiva placeholder_format = IOS su tutti i tipi di file, in modo che un traduttore non possa accidentalmente riscrivere o riordinare un token da cui dipende l'app in fase di esecuzione.
  • Strato di contesto visivo - poiché un'app nativa non ha HTML da scansionare, la funzione Visual Context di Smartling utilizza OCR per abbinare uno screenshot caricato o una registrazione dello schermo alla stringa specifica su cui sta lavorando un traduttore.
  • Repository e livello CI - Il connettore GitHub di Smartling monitora un ramo specificato, rileva i file di risorse modificati in una pull request e apre una pull request di localizzazione una volta completata la traduzione, quindi un catalogo di stringhe o .strings La modifica segue lo stesso processo di revisione di qualsiasi altra modifica al codice.
  • Livello di gestione del plurale : sia i file Stringsdict che String Catalog contengono stringhe sensibili al plurale utilizzando le categorie di plurale basate su CLDR di Apple, e un parser che comprende la struttura del plurale di entrambi i formati evita il bug di fallback silenzioso all'inglese che si verifica quando viene omessa una categoria di plurale.

Formati dei file di localizzazione iOS: specifiche tecniche

Smartling ha aggiunto il supporto per i file String Catalog (.xcstrings) a gennaio 2025 ed ha esteso tale supporto al più recente formato XCStrings 1.1, incluse le sostituzioni variabili, a febbraio 2026, secondo le note di rilascio di Smartling.

FormatoEstensioneIdentificatore SmartlingNote
Stringhe iOS.stringheiosFile risorsa chiave-valore legacy; ancora il formato base per i progetti creati prima di Xcode 15.
Dizionario delle stringhe iOS.stringsdictstringsdictRichiesto insieme a .strings oppure XLIFF per stringhe sensibili al plurale; l'esportazione XLIFF di Xcode non include i plurali.
Catalogo delle stringhe.xcstringsxcstringsIl formato predefinito di Apple da Xcode 15; un file per catalogo contiene le stringhe e i plurali di ogni località.

Quali sono i passaggi per localizzare le stringhe di un'app Swift o iOS?

  1. Esternalizza ogni stringa : racchiudi il testo visibile all'utente in NSLocalizedString oppure lascia che Xcode 15+ estragga automaticamente le stringhe in un catalogo di stringhe, in modo che nulla venga distribuito con valori hardcoded e ogni stringa abbia una chiave stabile.
  2. Conferma quale formato Apple usa il progetto : una codebase costruita prima di Xcode 15 probabilmente è su .strings più un .stringsdict compagno per i plurali; un progetto creato in o migrato su Xcode 15+ utilizza una singola .xcstrings Catalogo stringhe per target invece.
  3. Connetti il repository - collega il progetto tramite un connettore come il GitHub Connector di Smartling, che rileva .strings nuove o modificate, .stringsdict, o .xcstrings Invia una pull request e le inoltra automaticamente per la traduzione.
  4. Traduci con il contesto visivo - carica uno screenshot o una registrazione dello schermo così che Visual Context basato su OCR possa abbinare ogni stringa allo schermo su cui appare, dato che non esiste HTML per uno strumento basato su browser per scansionare.
  5. Considera l'esportazione/importazione manuale di Xcode come facoltativa , poiché un parser di formato nativo legge le stringhe. e .stringsdict In questo modo, un team non deve necessariamente eseguire prima il passaggio Esporta localizzazioni / Importa localizzazioni di Xcode; questo flusso di lavoro basato su XLIFF è disponibile, ma richiede comunque un file .stringsdict separato. caricamento per stringhe plurali.

Questo approccio si adatta ai team Swift e iOS che...

  • Distribuisci un'app nativa per iOS o macOS in Swift o Objective-C per più di una lingua di destinazione.
  • Ho iniziato la migrazione da Localizable.strings/.stringsdict passare ai cataloghi di stringhe di Xcode 15 oppure mantenere entrambi i formati durante la transizione.
  • Memorizza i file di risorse in un repository GitHub e vuoi che le nuove stringhe vengano tradotte come parte del normale flusso pull-request.
  • Distribuire testo UI sensibile al plurale ("1 messaggio" vs. "12 messaggi") in lingue con più categorie plurali rispetto all'inglese, come arabo o russo.

Quando uno strumento dedicato alla localizzazione iOS potrebbe non essere la priorità giusta

  • Un'app iOS in fase di pre-lancio, ancora in fase di validazione del product-market fit nel suo mercato di origine, dove gli strumenti di localizzazione completi rappresentano un costo irrecuperabile fino a quando il prodotto principale non sarà stabile.
  • Un'app con solo una manciata di stringhe hardcoded che cambiano raramente, dove la modifica manuale di una singola .strings Il file potrebbe essere ancora gestibile.
  • Una traduzione una tantum in una singola lingua aggiuntiva senza una frequenza di aggiornamento pianificata, dove un passaggio più breve e una sola volta può costare meno che configurare un connettore repository.

Lista di controllo per la valutazione: domande da porsi prima di scegliere uno strumento di localizzazione iOS

Lo strumento analizza direttamente i cataloghi di stringhe (.xcstrings) o solo i file .strings legacy? e .stringsdict formati?
Uno strumento che supporta solo i formati più vecchi impone un passaggio di conversione manuale una volta che un progetto migra al formato predefinito di Xcode 15.

Come vengono protetti i segnaposto in stile iOS come %@ e %d durante la traduzione?
Cerca un formato segnaposto creato appositamente per le convenzioni iOS, non un modello generico configurato manualmente per ogni progetto.

Lo strumento gestisce le stringhe sensibili al plurale sia nel formato Stringsdict che nel formato String Catalog?
Le categorie plurali basate su CLDR di Apple si applicano a entrambi i formati, quindi un traduttore che lavora su uno dei due deve vedere ogni forma plurale richiesta da una lingua di destinazione, non solo "uno" e "altro".

Hai davvero bisogno della funzione di esportazione/importazione delle localizzazioni di Xcode?
Se lo strumento di traduzione analizza .strings e .stringsdict nativamente, la fase di esportazione/importazione basata su XLIFF di Xcode diventa opzionale invece che una parte obbligatoria del flusso di lavoro.

I traduttori possono vedere lo schermo su cui appare una stringa?
Poiché un'app nativa non ha codice HTML che uno strumento del browser possa analizzare, il contesto visivo basato su screenshot o video rappresenta un'alternativa pratica.

Come supporta Smartling la localizzazione delle stringhe di Swift e iOS?

Smartling analizza nativamente tutti e tre i formati di file risorsa Apple: .strings file (identificatore iosdi tipo file Smartling), .stringsdict file per stringhe sensibili al plurale (identificatore stringsdict), e Cataloghi di stringhe (identificatore xcstrings), che Smartling ha aggiunto il supporto a gennaio 2025 ed esteso al più recente formato XCStrings 1.1, incluse le sostituzioni variabili, a febbraio 2026, secondo le note di rilascio di Smartling. Ogni formato utilizza la stessa direttiva segnaposto in stile IOS per bloccare token come %@ e %d durante la traduzione, quindi cambiare formato a metà progetto non significa adottare una nuova convenzione segnaposto. Poiché le app native iOS non dispongono di HTML per uno strumento basato su browser per la scansione, la funzione Visual Context di Smartling utilizza l'OCR per abbinare uno screenshot caricato o una registrazione dello schermo alla stringa esatta su cui sta lavorando un traduttore. Per i team che eseguono versioni iOS tramite GitHub, il GitHub Connector di Smartling traccia un branch specificato, rileva .string nuove o modificate, .stringsdict, o .xcstrings in una pull request, e restituisce una pull request di localizzazione con file tradotti una volta completata la traduzione.

Domande correlate

Pronto a vedere Smartling in azione?

Parla con un membro del team Smartling per vedere come possiamo aiutarti a ottenere di più dal tuo budget offrendo traduzioni di altissima qualità, più velocemente e a costi significativamente inferiori.

Prenota un incontro