Home Forums Bug Reports l10n: ACF translates label VALUES in group editing screens


l10n: ACF translates label VALUES in group editing screens

  • Using the acf/settings/l10n_textdomain filter it is possible to make ACF aware of a previously loaded textdomain to translate ACF field labels in the admin backend. I have been using this for a multilingual client installation that also requires a translated backend, and it is working as intended.

    However, the current behaviour leads to a bug: When editing an ACF field group while the admin interface is displayed in the translated language, the translated field labels are inserted as values for field names. Saving an edited group then would save the translated field names as the new field names, which in consequence breaks the translation setup.

    Currently, I mitigate this with a hotfix in functions.php hooked into the acf/settings/l10n filter, checking whether I am currently on an ACF group edit screen and disable l10n in that case:

    (Edit: See better version below.)

    But ideally, this should be addressed in the plugin itself.

  • I’m sorry to see that after 4 months this bug is still marked as “unread”, i.e. not even acknowledged. Is it too obscure, or did I do a bad job at describing it?

    For posterity, I ended up on the following hotfix. The additional test for the existence of get_current_screen() is necessary on some (unrelated) admin screens.

    function conditional_acf_set_l10n(){
    	if ( is_admin() ) {
    		if ( function_exists('get_current_screen') ) {
    			$current_screen = get_current_screen();
    			return ( $current_screen->post_type != 'acf-field-group' );
    	return true;
    add_filter( 'acf/settings/l10n', 'conditional_acf_set_l10n' );
Viewing 2 posts - 1 through 2 (of 2 total)

The topic ‘l10n: ACF translates label VALUES in group editing screens’ is closed to new replies.