[wp-trac] [WordPress Trac] #42725: Introduce gender compatible translation function, and gender user profile field

WordPress Trac noreply at wordpress.org
Sat Dec 2 19:09:10 UTC 2017


#42725: Introduce gender compatible translation function, and gender user profile
field
-------------------------+------------------------------
 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
> `neutral`. 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 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.

--

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


More information about the wp-trac mailing list