[wp-trac] [WordPress Trac] #42725: Allow gender specific translations (was: Introduce gender compatible translation function, and gender user profile field)

WordPress Trac noreply at wordpress.org
Thu Dec 14 13:34:39 UTC 2017


#42725: Allow gender specific translations
-------------------------+------------------------------
 Reporter:  yoavf        |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  I18N         |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------
Description changed by yoavf:

Old description:

> For years, the WordPress translators community has needed to resort to
> '''painful compromises''' for languages with grammatical gender, where
> women are often discriminated by default.
>
> From strings like `Lead Developer` to simply `Author` or `Editor`, some
> languages will always refer to these as males, regardless of the user
> self-identification.
>
> While modern English grammar is exceptionally capable of being gender
> neutral, many other languages do not share this trait. Forcing all
> languages to adopt a gender-neutral grammar, even when they're not
> capable of it, diminishes the appeal of WordPress to non-English speaking
> users, especially women - because in almost all languages, pseudo gender-
> neutral grammar just uses the male form.
>
> This ticket contains two patches.
> 1. `gender-to-user-profile.diff` adds a user profile field for users to
> select their preferred grammatical gender (or pronoun). The default is
> `unknown`. This field was inspired by Facebook's and Wikipedia's field.
> It also introduces a `get_current_user_gender()`  helper method to
> retrieve this field value.
>
> 2. `add-new-gender-translation-function.diff`: which adds a `_g()`
> function (also previously proposed in #36617 by @bastho), and support for
> it in `makepot.php` via an arguably simple prefix context hack, which
> makes it compatible with existing translation tool (see notes below about
> GlotPress support).
>
> ----
>
> '''Notes:'''
> - I added support in GlotPress for the `_wpg` context prefix via
> [https://github.com/GlotPress/GlotPress-WP/pull/855 GP Pull request 855]
> and the simple [https://github.com/yoavf/gp-gender gp-gender] plugin, to
> make the UI more cohesive.
> - The current patches are all fully functional but remain at the proof-
> of-concept level. A healthy discussion on the implementation and possible
> alternatives are more than welcome.
> - For simplicity purposes, `g()` '''assumes English will remain gender
> neutral,''' and so only takes one string as input. I'm happy to
> reconsider and let it have an optional three string input.
> - `_gx()` would be trivial to add, `gn()` not so much.
> - This proposal is part of my [https://2017.us.wordcamp.org/sessions
> /#wcorg-session-4139 WC US 2017 session].
> - Major props to @glueckpress for being a driving force in creating this
> with his [https://wordpress.tv/2017/06/27/caspar-hubinger-big-little-
> shame-a-tale-of-empowered-user-experience-through-localisation/ WC Europe
> 2017 talk].
>
> ----
>
> '''How _g() works:'''
> 1. When makepot/extract sees a `_g()` call, it just adds a `_wpg_`
> context to the string.
> 2. GlotPress, via the gp-gender plugin linked above, will store up to 3
> translations (unknown/female/male) for a string with the context `_wpg_`.
> 3. On export from GP, the output will contain three distinct entries,
> with either `_wgp_`, `_wpg_male_` or `_wpg_female_` as the context.
> 4. When rendering `_g()`, it will use the `_wpg_` context if the gender
> is unknown, otherwise, it will use either `_wpg_male_` or `_wpg_female_`.
>
> The only part I consider missing here, is that if there's no entry for
> `_wpg_male_` or `_wpg_female_`, `_g()` should fall back on the default
> entry.

New description:

 For years, the WordPress translators community has needed to resort to
 '''painful compromises''' for languages with grammatical gender, where
 women are often discriminated by default.

 From strings like `Lead Developer` to simply `Author` or `Editor`, some
 languages will always refer to these as males, regardless of the user
 self-identification.

 While modern English grammar is exceptionally capable of being gender
 neutral, many other languages do not share this trait. Forcing all
 languages to adopt a gender-neutral grammar, even when they're not capable
 of it, diminishes the appeal of WordPress to non-English speaking users,
 especially women - because in almost all languages, pseudo gender-neutral
 grammar just uses the male form.

 This ticket is a tracking ticket for the various tasks needed to allow for
 gender-specific translations

 '''How gender specific translations will work with gettext'''
 - We will modify some of the existing translations functions (in a
 backward compatible way) to accept an optional user gender value.
 - When this happens, the POT generation tools will create 3 different
 strings, differentiated by a specific context.
 - On output, the correct translation will be loaded based on the value of
 the gender property

 '''What needs to be done'''
 - Introduce a user profile field to store users' gender and a
 `get_user_gender()` function. See #42900
 - Add unit tests to current translation functions
 - Add an optional `options` parameter to `__()`, `_x()`, `_n()`, `_nx()`
 that will be used to pass the gender to the translation functions
 - Update documentation
 - Update GlotPress to group translations.

 ----

 '''Notes:'''
 - This ticket originally included proof-of-concept patches. It has since
 been rewritten to reference other tickets to tackle the various tasks.
 - The details of the implementation were discussed during contributor day
 at WCUS 2017. Big thanks to @gregross, @johnbillion, @nullbyte for making
 this happen, thanks to @nacin as well for his input.
 - Major props to @glueckpress for being a driving force in creating this
 with his [https://wordpress.tv/2017/06/27/caspar-hubinger-big-little-
 shame-a-tale-of-empowered-user-experience-through-localisation/ WC Europe
 2017 talk].

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42725#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list