Adjustable Textdomains and Textdomains in PHP Export

• danielpataki

• January 10, 2014 at 6:00 am

Hi Elliot,

As I am building our first production-ready theme I noticed that textdomains pose a problem in testing and the final build, here’s why.

The way we’re creating our theme options is that we’re keeping all of them contained inside the plugin so we can easily edit and modify. Then, before we publish we’ll export to PHP and include them as PHP.

Since initially the plugin adds its own textdomain (acf), if we translate these as a test, we will loose these translations once the test is complete, because we’d like the textdomain to be the name of the theme. This is not a huge obstacle, but it would be awesome if you could choose a textdomain from within the plugin, or perhaps by defining a constant.

The bigger issue is exporting to PHP. When you do that the export does not contain translation functions which means we’d need to mark all of them for translation. If the PHP export could have translations with a custom text domain it would be awesome!

Thanks for your time 🙂

Daniel

• Elliot

• January 11, 2014 at 12:17 pm

Hi @danielpataki

Thanks for the requests. I will be looking into the issue of translating the exported PHP fields soon.

As for the editable textdomain, I don’t quite understand why you would want to change this. What is the benifit?

Thanks
E

• danielpataki

• January 11, 2014 at 6:27 pm

Hi Elliot,

Thanks so much for looking into it! For the second issue, it would be great if I could choose a text domain by defining a constant for two reasons.

The main reason would be to make it blend into the theme more. We’re making premium themes and having two textdomains: “theme-frontend” and “theme-backend” is super obvious while “acf” would be a bit of a mystery without documentation. We can of course provide the documentation so it’s not a huge issue.

A smaller issue: after adding 20 or so fields we have 420-ish translatable strings, I am guessing that about 50 of these are our fields. If we want to provide translations for our fields we’d need to wade through the 420 instead of just going down a list of 50 or so. This is a minor considerations since we can do this on the PHP side, but it could be of some help.

Again, this second issue is just me being more of a control freak than needed, the translatable PHP strings would solve all our actually important issues 🙂

Thanks again!

Daniel

• atimmer

• December 3, 2014 at 12:03 am

I would love to have translatable strings as an export. What I mean is instead of the output being this:

'label'        => 'Label',
'name'         => 'label',
'instructions' => 'Instructions',

The output would be:

'label'        => __( 'Label' ),
'name'         => 'label',
'instructions' => __( 'Instructions' ),

A textdomain is fairly easy to add using a build process such as the ‘addtextdomain’ task in this grunt plugin: https://www.npmjs.org/package/grunt-wp-i18n.

I think the PHP tools within WordPress contain a similar function.

• kokers

• May 20, 2015 at 10:58 pm

This is something I dream about ;o) Please, please make translatable strings in PHP export.

Although I think it should add currently active textdomain and you can always use the “updateDomains” option in that grunt plugin.

EDIT:
It would be awesome to have an option for the use of _x() function similar to this:

_x('This is my label','ACF - Field group name','textdomain')

• kokers

• May 22, 2015 at 6:45 pm

If anyone is interested I’ve modified a file /wp-content/plugins/advanced-custom-fields-pro/admin/views/settings-export-generate.php

By adding this:

//textdomain and i18n for label
$code = preg_replace('/\'label\' => \'(.*)\'/', '\'label\' => _x(\'$1\',\'ACF - '.$field_groups[0]['title'].'\',\''.$current_textdomain.'\')',$code);

//textdomain and i18n for label
$code = preg_replace('/\'instructions\' => \'(.*)\'/', '\'instructions\' => _x(\'$1\',\'ACF - '.$field_groups[0]['title'].'\',\''.$current_textdomain.'\')',$code);

just before echo. There is only one thing I can’t figure out – as I genuinely hate regex – how to skip empty strings as this is also changed
'instructions'=>'' to _x('','ACF','textdomain')

This doesn’t work for choices in checkbox/select/radio etc and by looking at structure of the var_export it would be almost impossible to make “choice” translatable.

So I am thinking that maybe a way out would be in label/instructions/choices adding lang:My label name, and later search and replace everything that starts with lang: and make it as __() or_x() depending on preferences. It would have to be striped in the frontend tho, or maybe even changed in frontend to __(). That way it could work even without export.

What you think?

• Kevin Pliester

• January 17, 2020 at 5:40 am

It’s an older question, but since I was looking for a solution myself, here is mine:

$textdomain = 'textdomain';

$code = preg_replace( '/\'label\' => (.{3,})\,/', '\'label\' => esc_html_x( $1, \'ACF ' . $field_group['title'] . ' Label\', \'' . $textdomain . '\' ),', $code );
$code = preg_replace( '/\'instructions\' => (.{3,})\,/', '\'instructions\' => esc_html_x( $1, \'ACF ' . $field_group['title'] . ' Instructions\', \'' . $textdomain . '\' ),', $code );
$code = preg_replace( '/\'append\' => (.{3,})\,/', '\'append\' => esc_html_x( $1, \'ACF ' . $field_group['title'] . ' Append\', \'' . $textdomain . '\' ),', $code );
$code = preg_replace( '/\'prepend\' => (.{3,})\,/', '\'prepend\' => esc_html_x( $1, \'ACF ' . $field_group['title'] . ' Prepend\', \'' . $textdomain . '\' ),', $code );

@kokers you can use (.{3,}) instead of (.*). Then only matches with 3 or more chars are evaluated.

• MarcGuay

• March 4, 2021 at 2:49 am

For anyone coming across this in 2021 the solution is to set a textdomain via code like so:

add_action('acf/init', 'acf_l10n_textdomain_setting');
function acf_l10n_textdomain_setting()
{
    acf_update_setting('l10n_textdomain', 'yourtextdomain');
}

Once this setting is defined it will automatically wrap them on export.