3

I want to move to xliff instead of translating Localizable.strings and Main.strings files but I found out that I'm using NSLocalizedString in an improper way (and I did it for 5 years actually...).

I don't like to have the translations directly inside my code, so I use a generic key and I do not write any comments:

NSLocalizedString("general.error", comment: "")

Then I include the string into the Localizable.strings

"general.error" = "An error occured";

So far so good (maybe). Now when I export xliff files I see that the source is just my generic key and obviously a translator cannot guess what to write as target for that key :/

So my question is: Is the only solution to move all the translations directly inside the NSLocalizedString?

NSLocalizedString("An error occured", comment: "")

or inside the comment... (I really don't like this solution)

And what if the string is really long? it seems so strange to put a string of 3 rows directly into the code :/

Any other interesting solution out there?

EDIT

I've already tried to use constants, but it seems that this solution doesn't work in swift. I've created a String.swift file where I've added constants:

let thisIsMyLonStringID = "An here I can put the long translation";

And I can use it in this way:

NSLocalizedString(thisIsMyLonStringID, comment: "")

When I export to XLIFF this string is not available in the xliff files though :(

MatterGoal
  • 16,038
  • 19
  • 109
  • 186

3 Answers3

5

I put here an answer with my temporary solution. It seems to work pretty well actually.

Instead of using a Base language for the Localizable.strings file I've used English, so I've just deselected Base from the file inspector -> Localizations area in Xcode and I've been prompt with a question like "which language would you like to use as base"... I've selected english.

Now I can continue using NSLocalizedString using a generic key and putting the translations in Localizable.strings when I export to xliff automatically the source is filled with the right translation and not with the key.

MatterGoal
  • 16,038
  • 19
  • 109
  • 186
0

You need to make the call to NSLocalizedString directly in your Strings.swift file. For example:

// Strings.swift
let myString = NSLocalizedString("some very long string", comment: "")

// Usage
print(myString)

That way, the string export process will be able to determine the string literal that is passed in to NSLocalizedString.

Eric Fikus
  • 184
  • 4
-1

Yes there is very elegant solution to your problem. Problem is very long string's are getting part of our code, making it harder to read and messy.

Solution: Create LocalizationKeys.h

#ifndef Project_LocalizationKeys_h
#define Project_LocalizationKeys_h

static NSString *const LocalizationKeyForVeryLongString =
@"Your Very Very Long String";

#endif

In your code: ViewController.m

NSLocalizedString(LocalizationKeyForVeryLongString, "");

So above solution separated very long messy strings and replaced them with elegant and readable Key Strings, moreover now we have separate file for key strings, so whenever someone is needed to change or to lookup, directly refer to LocalizationKeys.h

Aamir
  • 16,329
  • 10
  • 59
  • 65
  • Actually this solution is not working for me (I'm using swift though). When I export for xliff all the keys that are not string literal are not exported. So If I use a constant like `my.key` instead of the final string `"My key"` xcode doesn't export it to xliff. – MatterGoal Jun 14 '16 at 09:29
  • To give you some more context. I've used a generic Strings.swift file and added some strings there using this code `let myVeryLongString = "this is a very long string";` and then I've used `NSLocalizedSrtring` as per your example... but this string doesn't get exported to the final xliff... maybe is a bug. – MatterGoal Jun 14 '16 at 09:30