[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