<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>

CC BY-SA 3.0
2014-11-04T21:38:55.400Z
2014-11-04T21:38:55.400Z
Brad Bell
<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>

<plugin-development>
Default locale in console commands is always en_us rather than the site default
# 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:
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();


---

