What is the use-case for this library compared to Xcode - Export for Localization and import?

[bobergj]

I am trying to better understand the use-case for this library compared to the standard localisation workflow in Xcode.

In the readme you say:

LocalizedStringKit is a tool that lets you write English strings directly into your source code and generate the required .strings files later. No more manually managing string keys or remembering to add them to the strings file later. All you do is change:
label.text = NSLocalizedString("TERMS_SCREEN_MAIN_HEADER", "Comment here...")
...

If you use NSLocalizedString, you can write English strings directly into the source code as the key parameter (in the same way as with the replacement function in this library). Then to generate the strings files for the other languages, in Xcode,

1. Select the project in the sidebar
2. Select, menu item Editor -> Export for Localization
3. Add the target translations to the resulting XLIFF
4. Then import again with Editor -> Import Localisation
   Result: Xcode will create the strings files and add them to the project

Furthermore, If you alternatively use keys such as NSLocalizedString("my.string.a", ..), you can export the development language, in the same way as described above, and import to generate the strings file for the development language.

Is this library for when you don't use Xcode, or don't want to use the xliff-based workflow (for some reason)?

[dalemyers]

That's a great question 😄

There are a few reasons. The first is that when this library was actually written, it was when Xcode 6 was the latest version and it would be another 4 years before this functionality arrived in Xcode. The second is that when this functionality arrived, we looked at it, but didn't move to it since our translation team depended on .strings files at the time (despite their obvious disadvantages over more powerful formats).

Both of these issues are non-issues now, so we could switch in theory. However, there is one significant advantage that this library has: It can be connected up to our CI system to ensure that strings have been exported in every PR. We don't run a risk of missing strings that way.

Going forward, we will absolutely be moving to a better localization format and will be updating this tool to support it, but there is no timeline for that yet.

One more thing: If the Xcode functionality works better for you (especially since it gives a more powerful format), please continue using it. We aren't trying to say this is the best way at all. It's just what we use and we wanted to make it available for anyone who had the same issues we have. We know those don't affect everyone as each code base is unique.