È sicuro utilizzare le chiavi "reali" in NSLocalizedString()? Esiste un linguaggio di riserva garantito?

Question

So che molti sviluppatori lo fanno in questo modo: iniziano a sviluppare la loro app in inglese e inseriscono NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...") anziché semplicemente @"Tap this to do that!".

Quindi eseguono genstrings che crea in qualche modo un file Localizable.strings estraendo tutte queste stringhe. La parte disordinata: il lungo testo utilizzato nel codice diventa la chiave. Funziona. Fino a un giorno in cui accedi rapidamente al tuo codice e modifica la stringa inglese e dimentichi la localizzazione e che funge da chiave per tutti i file Localizable.strings.

Quindi tendo ad usare i tasti "reali" che non si confondono con le stringhe. Per un test rapido ho creato un progetto localizzato in inglese e francese. Quindi ho impostato la lingua del simulatore in tedesco. Perché, sai, farebbe schifo terribilmente se l'utente vedesse la chiave come TTTDT.

Quindi, con solo inglese e tedesco, ho lanciato l'app demo. E quello che ho ottenuto è stato il testo inglese dal file Localizable.strings in inglese.

Conclusione: Sembra che NSLocalizedString ricada nel file inglese se la lingua del sistema operativo non è coperta dall'app.

quesion: presumere che vi sia sempre un file Localizable.strings (English), e le chiavi sono nel file con i valori correttamente formattati. Ci sono circostanze in cui NSLocalizedString fallirebbe e quindi visualizzare direttamente la chiave?

Answer 1

Per rispondere alla tua domanda: Sì, ho riscontrato il problema che ti preoccupa, ovvero i nomi dei tasti sono stati visualizzati anche se era presente un file localizable.strings e includeva voci per i nomi di tali chiavi. Questo accade quando hai più di un file localizable.strings nel tuo progetto. Che può facilmente accadere se si rilascia una serie di file da un progetto Open Source che ha il proprio localizable.strings (come ShareKit) nel progetto.

Here is a related question che discute questo problema.

Ma almeno se si utilizzano i nomi di chiavi in ​​stile ID, si noterà un tale problema quando si esegue il test dell'app in qualsiasi lingua. Se si utilizzava la chiave inglese (o lingua base) come chiave, non si vedrebbe questo problema insidioso finché non si testano le versioni localizzate e si potrebbe passare inosservati più facilmente.

Quindi, in cima al tuo punto su dover ricordare di aggiornare i tasti (in tutte le lingue) durante la riformulazione del testo, c'è il problema di nascondere potenziali bug quando si usa il testo inglese come chiave (l'inglese sembrerebbe OK, ma localizzato versioni non lo farebbero). Quindi mi sembra che usare i nomi di chiavi "reali" piuttosto che il testo reale sia più pratico. Se sei ancora preoccupato che per qualche motivo i nomi delle chiavi possano apparire, scegli una chiave che sia almeno sufficientemente descrittiva da essere comprensibile.

Answer 2

Tendiamo a utilizzare i tasti "reali" ma di solito sono il testo inglese (o una forma abbreviata) e aggiungiamo "Chiave" alla fine. In questo modo è chiaro.

Answer 3

Ho scritto un codice personalizzato che verifica effettivamente che tutte le chiavi nell'app compaiano in tutti i file localizable.string. Ci sono stati due passaggi per questo processo - utilizzando genstrings per generare un nuovo file di stringhe localizzabile contenente tutte le chiavi attualmente a cui si fa riferimento nell'origine. Poi ho usato alcune API-C obiettivo per caricare i miei file esistenti localizable.strings e ho confrontato che avevano tutti lo stesso set di chiavi (né più né meno) di quello appena generato.