NSLocalizedString in base language where key != value

Question

Created Jul ’16

Replies 2

Boosts 0

Views 1.9k

Participants 3

My server sends tokens representing strings. I map the token to a message to present to the user. This means that rather than using (in my case) the English version of the string as a key I use a different value. For example:

let _ = NSLocalizedString(“keystring", tableName: "Localizable", bundle: NSBundle.mainBundle(), value: “Tell us your thoughts", comment: "statically localized”)

I would then like use NSLocalizedString to retrieve the English version, the same as any other language. For example:

let key = “keystring”

let message = NSLocalizedString(key, comment: “”)

If I hand-craft a Localized.strings file like the following:

/ statically localized */

“keystring" = “Tell us your thoughts”;

then this works. The problem is that only in the first (Swift) case does the string get included in the generated XLIFF. In this case the translation at run-time doesn’t work, the return value from NSLocalizedString is the key itself. In the second case the lookup works but the string is not put in the XLIFF for translation.

My question is how to localize a string which has a key other than the value itself and later look it up. While the initial Swift invocation shown above does return the localized value, I am looking up the string based on a server value and therefore cannot structure my code this way.

Thanks,

Cliff

Boost

Answer 1

Ken Thomases OP

Jul ’16

I don't know if this works for Swift, but I assume so: put a bunch of "calls" to NSLocalizedString in comments to generate the strings to be translated. Basically, you would list all of the possible keywords and the English translation like that. The actual code would use the variable key that you receive from the server. As you've observed, that line would not generate any strings in the strings file, because its key is not a string literal.

0

Answer 2

QuinceyMorris OP

Jul ’16

Since you're talking about generating XLIFF files, I assume you mean that the list of possible tokens from the server is fully known in advance, yes?

In that case, I'd suggest you divide and conquer. Create an enum with a case for each possible token. For convenience, you could base this on String:

enum ServerResponse: String {
     case A = "keystringA"
     case B = "keystringB"

     var serverString: String {
          switch self {
          case A: return NSLocalizedString ("lookupstringA", "…") // you can re-use "keystringA" if you wish
          case B: return NSLocalizedString ("lookupstringB", "…")
          }
     }
}

When you get your server token, use ServerResponse(rawValue: token) to find (and validate!) its enum value immediately. Pass this value around in your code until you actually need the localized string, at which point you get serverResponse.serverString.

The payoff here is that you make the handling of the server response type-safe for as much of your code as possible (it spends as little time in String form as possible), plus you get automatic inclusion of the keys in the XLIFF file, plus you've decoupled a server requirement from a UI requirement, which seems like a net gain in app design terms.

0