Actually, there is not a simple solution for avoid the gender issue if you are translating a WP theme or plugin to languages that take into account the gender for selecting the words of a sentence. Simple, try to substitute the gendered words or expression for others that feet into the sentence without too many problems… But if you are not translating but creating a new theme or plugin you can use a simple set of techniques –better maybe suggestions–, that will allow future translators for dealing to this kind of problems with better results. Let’s go to see three simple proposals.

But, before to go to the solution, let me show you a tiny example of this kind of gender issues.

An example of different language gender translations

In this tiny example, we just want to show a string on the screen that simply says if something is good or bad:

In English you say:

• The wine is good.
• The recipe is good.
• The cat is good.

Of course, there is a gender inside the subject name but it’s not reflected in the sentences that are always the same, so an English-speaking programmer will write something like:

<?php echo sprintf( __( 'The %1$s is %2$s', 'textdomain' ), $item, $state) ); ?>

and that’s all… But, for example in spanish, Wines and Cats are male, and the Recipes are female. See the example of the translations in spanish

• El vino es bueno. (male) >> all sentences about wines will be constructed through male forms.
• La receta es buena. (female) >> all sentences about recipes will be constructed through female forms.
• El gato es bueno. (male) >> all sentences about cats will be constructed through male forms.

And in German, Wine is male, Recipe is neutral and Cat is female. See the example of the Translations in German

• Der wein ist gut. (male)
• Das rezept ist gut. (neutral)
• Die katze ist gut. (female)

The core of these proposals

Our problem in front of these gender issues is that neither PHP nor WordPress provided to us a set of tools for dealing to gender. Both PHP as WordPress have tools for dealing with plural forms (in some languages til 6 different forms of plural…) but there haven’t got any tool for gender (well, PHP has got one. Later I’ll talk about it).

The core of this proposals is to create a new variable that contains always the gender of the context where we are showing the data. And to create this new variable we have to take into account that WordPress core basically works with 4 kinds of information that could have gender: Post Types, Taxonomies, the Terms in a taxonomy, and the Users. For this proposal however, these 4 classes of information could be divided into just three different groups:

• Post Types and Taxonomies
• Terms
• Users (John, Laura and HAL-9000, for example)

And for each one of these three groups, we have to use a different way for marking its gender context. Today, we’ll develop the first of these three proposals.

Marking the gender of Post Types and Taxonomies

In the case of Post Types and Taxonomies, the most simple way for marking the gender of each one of these objects, specifically the gender of the items that usually belong to, (Cats, Recipies, Films, Forms, Cities… ), it is to add a new element to the array used for creating both of them through the functions register_post_type and register_taxonomy respectively. Afterwards, we have to mark the new element as a translated in a context with the  _x() WordPress function. See this example that modifies slightly the official example of register_post_type in WordPress.

add_action( 'init', 'codex_book_init' );
/**
 * Register a book post type.
 *
 * @link http://codex.wordpress.org/Function_Reference/register_post_type
 */
function codex_book_init() {
	$labels = array(
		'name'               => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
		'singular_name'      => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),
		'menu_name'          => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ),

                // some more labels... etc.

	);

	$args = array(
		'labels'             => $labels,
                'description'        => __( 'Description.', 'your-plugin-textdomain' ),
		'public'             => true,

                // some more vars... etc.

		'menu_position'      => null,
		'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),

                // this is our addition
                'gender'             => _x( 'male', 'gender of books', 'your-plugin-texdomain' ) 
	);

	register_post_type( 'book', $args );

}?>

Doing this, we mark successfully book as male –for example in spanish–, but in the future, if a translator changes the value of “gender” to female in the context of “gender of books” for his/her language then, the object Book becomes female.

Having done this addition to the array used by register_post_type(), then inside the single.php file of the WP Theme we can add a code like that:

//...

global $post;
$pt = get_post_type_object( $post->post_type );
$color = get_post_meta ( $post->ID,  'color', TRUE );
swicth ( $pt->gender ) {
    case: 'neutral';
        echo sprintf( _x( 'The %1$s is %2$s', 'translations for neutral', 'textdomain' ), $post->post_title, $color ); break;
    case: 'female';
        echo sprintf( _x( 'The %1$s is %2$s', 'translations for female', 'textdomain' ), $post->post_title, $color ); break;
    case: 'male';
        echo sprintf( _x( 'The %1$s is %2$s', 'translations for male', 'textdomain' ), $post->post_title, $color ); break;
    defualt:
        echo sprintf( _x( 'The %1$s is %2$s', 'translations for other cases', 'textdomain' ), $post->post_title, $color ); break;
}

// ...

Adding the gender value to all Post Types, an unique single.php file will be able to deal to all kind of them and will choose the correct translation according to gender because the translator will have translated the string of four _x() different functions instead of just one.

Of course, it is possible to use the same technique for marking a Taxonomy but, be carefull, in case of taxonomies, doing this probably we are just marking the object Taxonomy but not Terms that are included on it. In some cases, perhaps all the Terms of a Taxonomy belong to an unique gender but the most common situation is that each Term has got its own gender.

In case of taxonomies, this technique can be useful for example for strings like the header of a page that is a collection of items. For example, if we have two taxonomies: one for Emotions and another one for Colors, the header of the collection of items in these taxonomies in English could be:

Posts about the Emotion Hope, and
Post about the Color Red, respectively.

ie, a little fixed part ‘Posts about the’ followed by two more words –the taxonomy name and the Term– that are computed. In english, with a unique function like _e( 'Contents the about %s %s, $taxonomyName, $Term ); we’ll have got the solution however –for example in spanish–, the words ‘Emotion’ and ‘Color’ have got different gender so, in this case we should use the former technique

Entradas sobre la Emoción Esperanza, and
Entradas sobre el Color Rojo, respectively.

because in spanish even the fixed part of the string changes.

I hope that this technique will become usefull. In a few days, we’ll develop the other two cases: adding gender to Terms and adding gender to Users.

See the second article of this serie.

Have a nice WordPressing!