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

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.



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:


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:


For Matrix blocks, the namespacing scheme admittedly is a little bit ridiculous:


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 %}
    <li>{{ option.label|t }}: {{ option }}</li>
{% endfor %}
  • 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
    Feb 16 '16 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.