title: Best practice using NSLocalizedString
body: <p>I'm (like all others) using <code>NSLocalizedString</code>to localize my app.</p>
  
  <p>Unfortunately, there are several "drawbacks" (not necessarily the fault of NSLocalizedString itself), including</p>
  
  <ul>
  <li>No autocompletition for strings in Xcode. This makes working not only error-prone but also tiresome.</li>
  <li>You might end up redefining a string simply because you didn't know an equivalent string already existed (i.e. "Please enter password" vs. "Enter password first")</li>
  <li>Similarily to the autocompletion-issue, you need to "remember"/copypaste the comment strings, or else <code>genstring</code> will end up with multiple comments for one string</li>
  <li>If you want to use <code>genstring</code> after you've already localized some strings, you have to be careful to not lose your old localizations.</li>
  <li>Same strings are scattered througout your whole project. For example, you used <code>NSLocalizedString(@"Abort", @"Cancel action")</code> everywhere, and then Code Review asks you to rename the string to <code>NSLocalizedString(@"Cancel", @"Cancel action")</code> to make the code more consistent.</li>
  </ul>
  
  <p>What I do (and after some searches on SO I figured many people do this) is to have a seperate <code>strings.h</code> file where I <code>#define</code> all the localize-code. For example</p>
  
  <pre><code>// In strings.h
  #define NSLS_COMMON_CANCEL NSLocalizedString(@"Cancel", nil)
  // Somewhere else
  NSLog(@"%@", NSLS_COMMON_CANCEL);
  </code></pre>
  
  <p>This essentially provides code-completion, a single place to change variable names (so no need for genstring anymore), and an unique keyword to auto-refactor. However, this comes at the cost of ending up with a whole bunch of <code>#define</code> statements that are not inherently structured (i.e. like LocString.Common.Cancel or something like that). </p>
  
  <p>So, while this works somewhat fine, I was wondering how you guys do it in your projects. Are there other approaches to simplify the use of NSLocalizedString? Is there maybe even a framework that encapsulates it?</p>