Answers.Body: <p>Turns out this is actually a bug, too.</p>
  
  <p>It's going to end up being more involved to fix than a build release probably warrants, though, so it'll have to wait for the upcoming 2.3 release to get a proper fix.</p>
  
  <p>In the meantime, you'll be able to get by with your workaround of manually setting it.</p>
  
  <pre><code>$c-&gt;locale = craft()-&gt;i18n-&gt;getPrimarySiteLocale();
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-04T21:38:55.400Z
Answers.LastActivityDate: 2014-11-04T21:38:55.400Z
Answers.UserDisplayName: Brad Bell
Body: <p>The default (and only) locale for my site is <code>en</code>, however, when trying to query the <code>ElementService</code> from a console command without specifying the locale in the criteria, the locale used in the query is <code>en_us</code>. As such, the query returns no results. For example:</p>
  
  <pre><code>&lt;?php
  namespace Craft;
  
  class ShoppingCommand extends BaseCommand {
  
      public function actionListOrders() {
          $c = craft()-&gt;elements-&gt;getCriteria(ElementType::Entry);
          $c-&gt;section = 'orders';
          $c-&gt;limit = 5;
          foreach($c as $o) {
              print $o-&gt;id . ": " . $o-&gt;title . "\n";
          }
      }
  }
  </code></pre>
  
  <p>prints nothing, even though there are entries present for the default locale <code>en</code>.</p>
  
  <p>Printing out the query object <code>print_r(craft()-&gt;elements-&gt;buildElementsQuery($c));</code> shows the <code>:locale</code> parameter being passed to the sql query as <code>en_us</code>. But this locale doesn't even exist for the site (<code>select * from craft_locales</code> shows only <code>en</code>).</p>
  
  <p>The only way I could find to work around this is by adding the site's default locale to the criteria manually with:</p>
  
  <pre><code>$c-&gt;locale = craft()-&gt;i18n-&gt;getPrimarySiteLocale();
  </code></pre>
  
  <p>However, since the query works find without this when run in a controller, I'm skeptical that it should be needed. Is this is a bug, or is there some extra configuration i'm missing? Having some parameter to specify the locale to use for commands would make sense in mutli-locale environments, but I would still expect the default to be the site's default rather than <code>en_us</code>.</p>
  
Tags: <plugin-development>
Title: Default locale in console commands is always en_us rather than the site default
ThreadText: # Default locale in console commands is always en_us rather than the site default
  
  (Asked by: username_0 on 2014-11-04)
  
  The default (and only) locale for my site is `en`, however, when trying to query the `ElementService` from a console command without specifying the locale in the criteria, the locale used in the query is `en_us`. As such, the query returns no results. For example:
  
  ```
  <?php
  namespace Craft;
  
  class ShoppingCommand extends BaseCommand {
  
      public function actionListOrders() {
          $c = craft()->elements->getCriteria(ElementType::Entry);
          $c->section = 'orders';
          $c->limit = 5;
          foreach($c as $o) {
              print $o->id . ": " . $o->title . "\n";
          }
      }
  }
  
  ```
  
  prints nothing, even though there are entries present for the default locale `en`.
  
  Printing out the query object `print_r(craft()->elements->buildElementsQuery($c));` shows the `:locale` parameter being passed to the sql query as `en_us`. But this locale doesn't even exist for the site (`select * from craft_locales` shows only `en`).
  
  The only way I could find to work around this is by adding the site's default locale to the criteria manually with:
  
  ```
  $c->locale = craft()->i18n->getPrimarySiteLocale();
  
  ```
  
  However, since the query works find without this when run in a controller, I'm skeptical that it should be needed. Is this is a bug, or is there some extra configuration i'm missing? Having some parameter to specify the locale to use for commands would make sense in mutli-locale environments, but I would still expect the default to be the site's default rather than `en_us`.
  
  **Tags:** plugin-development
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-11-04. Score: 1 | Accepted answer
  
  Turns out this is actually a bug, too.
  
  It's going to end up being more involved to fix than a build release probably warrants, though, so it'll have to wait for the upcoming 2.3 release to get a proper fix.
  
  In the meantime, you'll be able to get by with your workaround of manually setting it.
  
  ```
  $c->locale = craft()->i18n->getPrimarySiteLocale();
  
  ```
  
  
  ---
  
  