Make WordPress Core

Changes between Version 12 and Version 15 of Ticket #42725

12/14/2017 01:34:38 PM (6 years ago)


  • Ticket #42725

    • Property Summary changed from Introduce gender compatible translation function, and gender user profile field to Allow gender specific translations
  • Ticket #42725 – Description

    v12 v15  
    55While 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.
    7 This ticket contains two patches.
    8 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.
     7This ticket is a tracking ticket for the various tasks needed to allow for gender-specific translations
    10 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).
     9'''How gender specific translations will work with gettext'''
     10- We will modify some of the existing translations functions (in a backward compatible way) to accept an optional user gender value.
     11- When this happens, the POT generation tools will create 3 different strings, differentiated by a specific context.
     12- On output, the correct translation will be loaded based on the value of the gender property
     14'''What needs to be done'''
     15- Introduce a user profile field to store users' gender and a `get_user_gender()` function. See #42900
     16- Add unit tests to current translation functions
     17- Add an optional `options` parameter to `__()`, `_x()`, `_n()`, `_nx()` that will be used to pass the gender to the translation functions
     18- Update documentation
     19- Update GlotPress to group translations.
    15 - I added support in GlotPress for the `_wpg` context prefix via [ GP Pull request 855] and the simple [ gp-gender] plugin, to make the UI more cohesive.
    16 - 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.
    17 - 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.
    18 - `_gx()` would be trivial to add, `gn()` not so much.
    19 - This proposal is part of my [ WC US 2017 session].
     24- This ticket originally included proof-of-concept patches. It has since been rewritten to reference other tickets to tackle the various tasks.
     25- 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.
    2026- Major props to @glueckpress for being a driving force in creating this with his [ WC Europe 2017 talk].
    22 ----
    24 '''How _g() works:'''
    25 1. When makepot/extract sees a `_g()` call, it just adds a `_wpg_` context to the string.
    26 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_`.
    27 3. On export from GP, the output will contain three distinct entries, with either `_wgp_`, `_wpg_male_` or `_wpg_female_` as the context.
    28 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_`.
    30 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.