<blockquote>
  <p>Short of hardcoding all these checkbox values and applying the translate tag on them</p>
</blockquote>

<p>That's actually the only way to translate field names, checkbox labels/values and whatnot: taking advantage of Craft's <a href="https://craftcms.com/support/static-translations">static text translation</a> feature by hard coding the strings you want to translate in a translations file (e.g. <code>/translations/en.php</code>). </p>

<p>An example: If one of your <code>whiskey</code> field's option labels is <strong>"Irish"</strong>, but you want it to be <strong>"Welsh"</strong> for a certain locale, you can add the following to the returned array in that locale's translation file:</p>

<pre><code>'Irish' =&gt; 'Welsh',
</code></pre>

<p>Of course, it's also possible to translate the field name itself, i.e.</p>

<pre><code>'Whiskey' =&gt; 'Whisky',
</code></pre>

<p>There's a big problem though – Craft's static text translation has no idea about context, meaning that it's not possible to tell Craft that the above translations belong to the <code>whiskey</code> field only. In other words, both <code>Whiskey</code> and <code>Irish</code> will be translated <em>across the board</em>. Sometimes that's what you'd want, but often it's not – a translated value may work in one place, but not in another.</p>

<p>One way to solve this, is to use <em>namespacing</em> for all the static strings you want to translate. The naming convention is entirely up to you, but here's how I do it for fields – the following two values are used for the field's name and instructions, respectively:</p>

<pre><code>field.whiskey.name
field.whiskey.instructions
</code></pre>

<p>With this namespacing pattern, the first part is the type of content this string belongs to (a field), the second part is the field's handle (which is obviously <em>never</em> translated) and the last part is what the string actually <em>is</em> (the name and the instructions, respectively). This works for other types of content as well, consider <code>section.news.name</code>, <code>entryType.link.name</code>, <code>categoryGroup.editors.name</code> etc.</p>

<p>For "nested" properties, such as a checkbox option's label, I usually write them out like this:</p>

<pre><code>field.whiskey.option.irish.label
</code></pre>

<p>For Matrix blocks, the namespacing scheme admittedly is a little bit ridiculous:</p>

<pre><code>field.someMatrixField.block.bio.name
field.someMatrixField.block.bio.text.name
field.someMatrixField.block.bio.text.instructions
</code></pre>

<p>The big downside to namespacing field names, option labels, section names etc. is that you have to add a translation for <em>all</em> locales (even your "default" locale), in order to not have the namespaced, "raw" value displayed to your users. In other words, it's definitely a bit more work than just translating plain ol' strings, but the big win is having granular control over all your translated fields, and being able to translate the same value differently for different use cases. It's the only way to go, in my opinion – at least when you have a fair number of strings to translate.</p>

<p>Anyway, here's how your translations file (e.g. <code>/translations/en.php</code>) could look with namespacing for the <code>whiskey</code> field:</p>

<pre><code>return [
    'field.whiskey.name' =&gt; 'Whiskey',
    'field.whiskey.option.irish.label' =&gt; 'Welsh',
];
</code></pre>

<p>As for the frontend, your static string translations will work there, too – just add the <code>|t</code> filter to the labels:</p>

<pre><code>{% for option in entry.whiskey.options %}
    &lt;li&gt;{{ option.label|t }}: {{ option }}&lt;/li&gt;
{% endfor %}
</code></pre>

CC BY-SA 3.0
2016-02-16T18:28:31.070Z
Thanks, @MatsMikkelRummelhoff for the detailed answer! The namespacing method looks promising but for now I'll just tell the client they'll have to stick with English filters for now.
bert_teng
CC BY-SA 3.0
2016-02-16T10:11:38.020Z
2016-02-16T10:11:38.020Z
Mats Mikkel Rummelhoff
<p>So I have a checkbox field in the new entry editor page. Attached image is an example of said checkbox. Just a standard checkbox field.
<a href="https://i.sstatic.net/VkyXn.png" rel="noreferrer"><img src="https://i.sstatic.net/VkyXn.png" alt="Just a regular checkbox field"></a></p>

<p>Is there a way for these checkboxes to be translatable? I'm redisplaying these checkboxes again in the front-end as filters so users can click the any of the checkboxes and the entries display will be filtered based on their input.</p>

<p>Short of hardcoding all these checkbox values and applying the translate tag on them, I'm not sure what else I can do.</p>

<p>Thanks!</p>

<localization>
Is there a way to have checkbox field labels translatable?
# Is there a way to have checkbox field labels translatable?

(Asked by: username_0 on 2016-02-16)

So I have a checkbox field in the new entry editor page. Attached image is an example of said checkbox. Just a standard checkbox field.
[![Just a regular checkbox field](https://i.sstatic.net/VkyXn.png)](https://i.sstatic.net/VkyXn.png)

Is there a way for these checkboxes to be translatable? I'm redisplaying these checkboxes again in the front-end as filters so users can click the any of the checkboxes and the entries display will be filtered based on their input.

Short of hardcoding all these checkbox values and applying the translate tag on them, I'm not sure what else I can do.

Thanks!

**Tags:** localization

---

## 1 answers

### Answer by username_1 on 2016-02-16. Score: 7 | Accepted answer

Short of hardcoding all these checkbox values and applying the translate tag on them

That's actually the only way to translate field names, checkbox labels/values and whatnot: taking advantage of Craft's static text translation feature by hard coding the strings you want to translate in a translations file (e.g. /translations/en.php). 
An example: If one of your whiskey field's option labels is "Irish", but you want it to be "Welsh" for a certain locale, you can add the following to the returned array in that locale's translation file:
'Irish' => 'Welsh',

Of course, it's also possible to translate the field name itself, i.e.
'Whiskey' => 'Whisky',

There's a big problem though – Craft's static text translation has no idea about context, meaning that it's not possible to tell Craft that the above translations belong to the whiskey field only. In other words, both Whiskey and Irish will be translated across the board. Sometimes that's what you'd want, but often it's not – a translated value may work in one place, but not in another.
One way to solve this, is to use namespacing for all the static strings you want to translate. The naming convention is entirely up to you, but here's how I do it for fields – the following two values are used for the field's name and instructions, respectively:
field.whiskey.name
field.whiskey.instructions

With this namespacing pattern, the first part is the type of content this string belongs to (a field), the second part is the field's handle (which is obviously never translated) and the last part is what the string actually is (the name and the instructions, respectively). This works for other types of content as well, consider section.news.name, entryType.link.name, categoryGroup.editors.name etc.
For "nested" properties, such as a checkbox option's label, I usually write them out like this:
field.whiskey.option.irish.label

For Matrix blocks, the namespacing scheme admittedly is a little bit ridiculous:
field.someMatrixField.block.bio.name
field.someMatrixField.block.bio.text.name
field.someMatrixField.block.bio.text.instructions

The big downside to namespacing field names, option labels, section names etc. is that you have to add a translation for all locales (even your "default" locale), in order to not have the namespaced, "raw" value displayed to your users. In other words, it's definitely a bit more work than just translating plain ol' strings, but the big win is having granular control over all your translated fields, and being able to translate the same value differently for different use cases. It's the only way to go, in my opinion – at least when you have a fair number of strings to translate.
Anyway, here's how your translations file (e.g. /translations/en.php) could look with namespacing for the whiskey field:
return [
    'field.whiskey.name' => 'Whiskey',
    'field.whiskey.option.irish.label' => 'Welsh',
];

As for the frontend, your static string translations will work there, too – just add the |t filter to the labels:
{% for option in entry.whiskey.options %}
    {{ option.label|t }}: {{ option }}
{% endfor %}

> **Comments:**
> **username_0**: Thanks, @MatsMikkelRummelhoff for the detailed answer! The namespacing method looks promising but for now I'll just tell the client they'll have to stick with English filters for now.  

---

