Come prepararsi alla localizzazione (HTML)

  • Articolo

[ Questo articolo è rivolto agli sviluppatori per Windows 8.x e Windows Phone 8.x che realizzano app di Windows Runtime. Gli sviluppatori che usano Windows 10 possono vedere Documentazione aggiornata ]

Segui i passaggi e le procedure consigliate descritte in questa sezione per preparare la tua app per la localizzazione. Prima di incominciare, leggi l'elenco di controllo per la globalizzazione per verificare che la tua app sia pronta per altri mercati, aree o lingue.

Istruzioni

Usare file di risorse e qualificatori

Accertati di specificare le risorse stringa nei file di risorse. Per ulteriori informazioni, vedi Guida introduttiva: Traduzione delle risorse dell'interfaccia utente.

Specifica le immagini e altre risorse file con il tag di lingua appropriato nel relativo file o cartella. Considera che è necessaria una significativa quantità di risorse del sistema per localizzare immagini, audio e video, quindi è preferibile usare asset di file multimediali neutrali quando possibile. Per ulteriori informazioni, vedi Come assegnare un nome alle risorse con i qualificatori.

Aggiungere commenti contestuali

Aggiungi commenti di localizzazione ai file di risorse della tua app. I commenti sono visibili al localizzatore e devono fornire informazioni contestuali che aiutino tale strumento a tradurre le risorse in modo accurato. I commenti devono anche fornire informazioni sufficienti sui vincoli in modo che la traduzione non danneggi il software. Facoltativamente, i commenti possono essere registrati mediante lo strumento Makepri.exe.

ResJSON consente l'uso nei campi dei metadati che iniziano con un carattere di sottolineatura, come i commenti:

{
    "String"  : "Hello World",
    "_String1.comment" : "This is a comment to the localizer"
}

Localizzare frasi anziché parole

Considera la stringa seguente: "The {0} could not be synchronized".

{0} può essere sostituito da diverse parole, ad esempio appuntamento, attività o documento. Se l'esempio non crea problemi nella lingua inglese, la frase corrispondente non funziona in tutti i casi in tedesco. Osserva che, nelle seguenti frasi in tedesco, alcune parole nella stringa modello ("Der", "Die", "Das") devono corrispondere alla parola con parametri:

Inglese Tedesco
The appointment could not be synchronized. Der Termin konnte nicht synchronisiert werden.
The task could not be synchronized. Die Aufgabe konnte nicht synchronisiert werden.
The document could not be synchronized. Das Dokument konnte nicht synchronisiert werden.

 

Un altro esempio può essere la frase "Remind me in {0} minute(s)." Sebbene "minute(s)" funzioni per la lingua inglese, altre lingue potrebbero usare termini diversi. Ad esempio, la lingua polacca usa "minuta", "minuty" o "minut" in base al contesto.

Per risolvere il problema, localizza l'intera frase anziché una singola parola. Questa procedura può sembrare più lunga e complicata, ma è la soluzione migliore per i seguenti motivi:

  • Verrà visualizzato un messaggio di errore corretto per tutte le lingue.
  • Il localizzatore non avrà dubbi sulla sostituzione delle stringhe.
  • Non è necessario implementare una costosa correzione del codice quando si presenta un problema di questo tipo dopo il completamento dell'app.

Verificare l'ordine corretto dei parametri

Non partire dal presupposto che tutte le lingue usano i parametri nello stesso ordine. Ad esempio, considera la stringa "Every %s %s", dove la prima variabile %s viene sostituita dal nome di un mese e la seconda variabile %s viene sostituita dalla data del mese. Questo esempio funziona per la lingua inglese, ma genera un errore quando l'app è localizzata in tedesco, lingua in cui la data e il mese vengono visualizzati in ordine inverso.

Per risolvere il problema, modifica la stringa in "Every %1 %2", in modo che l'ordine sia intercambiabile in base alla lingua.

Non esagerare nella localizzazione

Localizza stringhe specifiche, non i tag. Considera gli esempi che seguono:

Stringa eccessivamente localizzata Stringa localizzata in modo corretto
<link>condizioni per l'utilizzo</link> condizioni per l'utilizzo
<link>informativa sulla privacy</link> informativa sulla privacy

 

Se includi il tag <link> nelle risorse, verrà localizzato anch'esso, perdendo in questo modo validità. Solo le stringhe effettive devono essere localizzate. In generale, i tag devono essere considerati come codice che deve essere tenuto separato dal contenuto localizzabile. Alcune stringhe lunghe devono tuttavia includere markup per conservare il contesto e garantire l'ordine corretto.

Non utilizzare le stesse stringhe in contesti differenti

A volte può sembrare utile riutilizzare una stringa, ma ciò può causare problemi di localizzazione se la stessa parola o frase può avere significati o contesti diversi.

Puoi riutilizzare le stringhe se i contesti sono gli stessi. Ad esempio, puoi riutilizzare la stringa "Volume" per il volume degli effetti audio e per il volume della musica poiché entrambi fanno riferimento all'intensità del suono. Non riutilizzare la stessa stringa per fare riferimento al volume di un disco rigido poiché il contesto e il significato sono diversi, pertanto la parola potrebbe essere tradotta diversamente.

Un altro esempio è rappresentato dall'uso delle stringhe "on" e "off". In inglese "on" e "off" possono essere usati per l'attivazione/disattivazione della modalità Aereo, della funzionalità Bluetooth e dei dispositivi. In italiano invece la traduzione dipende dal contesto di ciò che viene attivato e disattivato. Dovresti quindi creare una coppia di stringhe per ogni contesto.

Inoltre una stringa quale "text" o "fax" può essere usata sia come verbo che come sostantivo in inglese, complicando il processo di traduzione. Crea invece una stringa diversa per il formato verbale e per quello nominale. Se non sei sicuro se i contesti siano gli stessi, non rischiare e usa una stringa diversa.

Identificare le risorse con attributi univoci

Gli identificatori delle risorse non fanno distinzione tra maiuscole e minuscole e devono essere univoci per ogni file di risorse. Quando accedi a una risorsa, usa l'identificatore della risorsa anziché il suo valore effettivo. Gli identificatori delle risorse non cambiano, a differenza dei relativi valori effettivi che cambiano in base alla lingua.

Accertati di usare identificatori delle risorse significativi per fornire maggiore contesto per la traduzione.

Non modificare gli identificatori delle risorse dopo che le risorse stringa sono passate alla fase di traduzione. I team di localizzazione usano gli identificatori delle risorse per tenere traccia di aggiunte, eliminazioni e aggiornamenti nelle risorse. Le modifiche apportate agli identificatori delle risorse—anche definite "cambiamenti degli identificatori delle risorse"—richiedono la traduzione delle stringhe poiché è come se le stringhe venissero eliminate e ne venissero aggiunte altre.

Scegliere un approccio di traduzione appropriato

Quando le stringhe sono state separare in file di risorse, possono essere tradotte. Il momento ideale per tradurre le stringhe è dopo la loro finalizzazione nel progetto, che in genere avviene verso la fine del progetto. Puoi affrontare il processo di traduzione in diversi modi. La scelta varia a seconda del volume di stringe da tradurre, dal numero di lingue in cui eseguire la traduzione e dalle modalità di traduzione, ad esempio internamente oppure incaricando un fornitore esterno.

Considera le opzioni seguenti:

  • I file di risorse possono essere tradotti aprendoli direttamente nel progetto. Questo approccio è ideale per un progetto con un volume ridotto di stringhe da tradurre in due o tre lingue. Potrebbe essere adatto a uno scenario in cui uno sviluppatore parla più lingue ed è disposto a occuparsi del processo di traduzione. Questo approccio ha il vantaggio di essere rapido, non richiede strumenti e riduce il rischio di traduzioni errate, ma non è scalabile. In particolare, le risorse in varie lingue possono facilmente perdere la sincronizzazione, causando un'esperienza utente negativa e problemi di manutenzione.
  • I file di risorse di tipo stringa sono in formato di testo XML o ResJSON, pertanto possono essere sottoposti a traduzione usando qualsiasi editor di testo. I file tradotti potrebbero quindi essere ricopiati nel progetto. Questo approccio comporta il rischio che i traduttori possano accidentalmente modificare i tag XML, ma consente lo svolgimento del lavoro di traduzione al di fuori del progetto di Microsoft Visual Studio. Questo approccio può essere adatto a progetti che devono essere tradotti in poche lingue. Il formato XLIFF è un formato XML progettato in modo specifico per la localizzazione ed è supportato da vari fornitori e strumenti di localizzazione. È possibile usare il Multilingual App Toolkit per generare file XLIFF da altri file di risorse, ad esempio .resw o .resjson.

Per altri tipi di file, ad esempio i file di immagini o audio, può essere necessario delegare il compito ai localizzatori. In genere non è consigliabile creare file che dipendono dalle diverse culture poiché possono essere difficili da localizzare.

Considera inoltre i seguenti suggerimenti:

  • Usa uno strumento di localizzazione. Sono disponibili alcuni strumenti di localizzazione per analizzare i file di risorse e consentire ai traduttori la modifica solo delle stringhe traducibili. Questo approccio consente di ridurre il rischio che un traduttore modifichi accidentalmente i tag XML. Tuttavia, implica anche l'introduzione di un nuovo strumento e di un'altra procedura nel processo di localizzazione. Uno strumento di localizzazione è utile per progetti con un gran numero di stringhe e un numero limitato di lingue. Per altre informazioni, vedi Multilingual App Toolkit.
  • Usa un fornitore di localizzazione. Prendi in considerazione l'eventualità di usare un fornitore di localizzazione se il tuo progetto contiene un elevato volume di stringhe e deve essere tradotto in molte lingue. Un fornitore di servizi di localizzazione può offrire consigli sugli strumenti, i processi e la traduzione dei tuoi file di risorse. Si tratta di una soluzione ideale, ma anche dell'opzione più costosa e può allungare i tempi necessari per ottenere il contenuto tradotto.
  • Fornisci informazioni ai localizzatori. Segnala ai localizzatori eventuali stringhe che possono essere considerate un sostantivo o un verbo. Spiega ai localizzatori le parole inventate usando strumenti terminologici. Controlla la grammatica e la chiarezza delle stringhe, nonché l'uso di un linguaggio semplice per evitare confusione.

Tasti di scelta ed etichette

La "sincronizzazione" dei tasti di scelta usati per l'accessibilità con la visualizzazione dei tasti di scelta localizzati è un compito arduo per la localizzazione in quanto le due risorse stringa sono classificate in due sezioni separate. È importante seguire la procedura di implementazione mostrata di seguito e commentare correttamente la stringa dell'etichetta che la collega alla definizione del tasto di scelta.

<label id="theLabel" data-win-res="{accessKey: 'theLabelAccessKey'}" for="xPrinterRedirection" accessKey="L">The <u>L</u>abel</label>
<input type="checkbox" value="OFF" id="xPrinterRedirection" name="xPrinterRedirection" />

Accertati di fornire commenti di questo tipo: Make sure that <u>L</u> is synchronized with the access key "theLabelAccessKey"

Supportare caratteri furigana per le stringhe giapponesi da ordinare

I caratteri Kanji giapponesi hanno la proprietà univoca di avere più di una pronuncia in base alla parola e al contesto in cui vengono usati. Si presentano pertanto dei problemi quando si tenta di ordinare gli oggetti denominati in giapponese, tra cui nomi di applicazioni, file, brani e così via. I caratteri Kanji giapponesi in passato sono stati in genere disposti in un ordine comprensibile dai computer, definito XJIS. Purtroppo, però, si tratta di un ordinamento non fonetico e quindi non particolarmente utile per le persone.

I caratteri furigana risolvono questo problema in quanto consentono all'utente o al creatore di specificare la fonetica dei caratteri che usa. Se usi la procedura seguente per aggiungere caratteri furigana al nome della tua app, puoi accertarti che venga ordinato nella posizione corretta all'interno dell'elenco di app. Se il nome della tua app contiene caratteri Kanji e non vengono forniti caratteri furigana quando si imposta la lingua dell'interfaccia utente dell'utente o l'ordinamento sul giapponese, Windows tenta di generare la pronuncia appropriata. Esiste tuttavia la possibilità che, se i nomi dell'app prevedono pronunce rare o univoche, vengano invece ordinati secondo una pronuncia più comune. Per le applicazioni giapponesi (soprattutto per quelle il cui nome contiene caratteri Kanji) è quindi consigliabile fornire una versione del nome in caratteri furigana durante il processo di localizzazione giapponese.

  1. Aggiungi "ms-resource:Appname" come valore di Nome visualizzato pacchetto e Nome visualizzato applicazione.

  2. In strings crea una cartella ja-JP e aggiungi due file di risorse come segue:

    strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw

  3. In Resources.resw per la lingua ja-JP generica aggiungi una risorsa di tipo stringa per il nome dell'app "希蒼"

  4. In Resources.altform-msft-phonetic.resw per le risorse in giapponese furigana aggiungi un valore furigana per il nome dell'app "のあ"

L'utente può cercare il nome dell'app "希蒼" usando sia il valore furigana "のあ" (noa) che il valore fonetico (tramite la funzione GetPhonetic di Input Method Editor (IME)) "まれあお" (mare-ao).

L'ordinamento segue il formato internazionale del Pannello di controllo:

  • Con impostazioni locali dell'utente in giapponese:
    • Se i caratteri furigana sono abilitati, "希蒼" viene ordinato sotto "の".
    • Se il valore furigana manca, "希蒼" viene ordinato sotto "ま".
  • Con impostazioni locali dell'utente diverse dal giapponese:
    • Se i caratteri furigana sono abilitati, "希蒼" viene ordinato sotto "の".
    • Se il valore furigana manca, "希蒼" viene ordinato sotto "漢字".