2013-11-25 5 views
16

Ho un progetto iOS che è localizzato in 16 lingue. Solo alcune parole non sono localizzate (principalmente quelle che entrano in un aggiornamento e l'ufficio di localizzazione non ha consegnato in tempo). Per le mie chiavi faccio non uso la dicitura inglese, in quanto ciò può anche cambiare se un traduttore lo desidera. Quindi ora se non ho una traduzione per una lingua, se ricade alla chiave che ho usato. Ma dal momento che questa chiave non è "leggibile dall'uomo" o almeno non "umana piacevole da leggere", questo è un problema.Fallback language iOS (con file Localizable.strings incompleto)

Ho fatto qualche ricerca ma non sono riuscito a trovare una soluzione a il mio esatto problema. devo fe .:

Localizable.strings in en.lproj 
@"Key1" = @"Value 1" 
@"Key2" = @"Value 2" 

Localizable.strings in de.lproj 
@"Key1" = @"Wert 1" 
// Note that @"Key2" is missing here in my de.lproj 

I would expect that if I make NSLocalizedString(@"Key2", ...) 
and am running on a german phone, it falls back to the english 
translation for this key as it exists... 

Quindi per ora ho solo copiato la traduzione in inglese nei file Localizable.strings mancanti. Ma questo è un grosso trucco! Ma anche usare le parole inglesi come chiavi sembra essere un trucco per me!

C'è un modo per dire alla mia app, che dovrebbe usare f.e. l'inglese come fallback se non c'è valore per una data chiave? Ho provato ad aggiungere una localizzazione di base, ma questo non aiuta ...

Grazie mille

+0

"Ma anche usare le parole inglesi come chiavi sembra essere un trucco per me!" -- Affatto. È una soluzione piuttosto elegante e risolve esattamente il problema che stai descrivendo. Solo perché il traduttore potrebbe cambiare le parole effettivamente utilizzate nella traduzione inglese, non significa che la chiave debba cambiare. Detto questo, la nuova localizzazione di base che Maxthon menziona è un approccio ancora migliore per la maggior parte del tempo. –

risposta

14

Per quanto ne so, non c'è modo "ufficiale" per farlo, ma ho implementato le funzioni di questo tipo prima:

NSString * L(NSString * translation_key) { 
    NSString * s = NSLocalizedString(translation_key, nil); 
    if (![[[NSLocale preferredLanguages] objectAtIndex:0] isEqualToString:@"en"] && [s isEqualToString:translation_key]) { 
     NSString * path = [[NSBundle mainBundle] pathForResource:@"en" ofType:@"lproj"]; 
     NSBundle * languageBundle = [NSBundle bundleWithPath:path]; 
     s = [languageBundle localizedStringForKey:translation_key value:@"" table:nil]; 
    } 
    return s; 
} 

mutuato da: https://stackoverflow.com/a/8784451/1403046

Fondamentalmente, invece di NSLocalizedString(), che restituisce la stringa di input, questa versione il fallback per inglese se necessario.

+0

Che schifo ... :) Il problema è che se uso L (...) i genstring (usati da Linguan) non lo troveranno ... ma grazie per la tua risposta ... se non otterrò un'altra risposta è meglio, accetterò presto il tuo. Saluti! – Georg

+0

È possibile passare '-s' a genstrings per dirgli quale funzione utilizzare al posto di NSLocalizedString. –

+1

Non posso credere che questo non sia stato costruito dopo tutti questi anni ... – Thomas

-3

È possibile utilizzare una localizzazione Base e verranno prese tutte le stringhe non localizzate.

+8

Ho aggiunto una localizzazione di base per le mie localizable.strings ma non sta prendendo le localizzazioni mancanti dal loro ... Speravo che sarebbe stato fatto , ma non è ... C'è qualche impostazione che devo attivare in Xcode? – Georg

+0

Non è vero. O mi manca qualcosa – jlmg5564

+0

No, questo non aiuta. [Base Internationalization] (https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/InternationalizingYourUserInterface/InternationalizingYourUserInterface.html) semplicemente separiamo le stringhe localizzabili dai tuoi xib o storyboard in file di stringhe che sono sicuramente di grande aiuto ma non risolvono nulla qui. – JonEasy

0

Ispirato this e this, la mia versione del codice Swift:

public func LS(_ key: String) -> String { 
    let value = NSLocalizedString(key, comment: "") 
    if value != key || NSLocale.preferredLanguages.first == "en" { 
     return value 
    } 

    // Fall back to en 
    guard 
     let path = Bundle.main.path(forResource: "en", ofType: "lproj"), 
     let bundle = Bundle(path: path) 
     else { return value } 
    return NSLocalizedString(key, bundle: bundle, comment: "") 
} 

Molti sviluppatori si aspettano una traduzione incompleta per fallback sul linguaggio di sviluppo .. ma non è questo il modo in cui Apple choose to behave. Ho un pseudocode per aiutare a capire meglio come Apple sceglie di fallback.