| 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 |
| | 13 | |
| | 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 [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. |
| 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 [https://2017.us.wordcamp.org/sessions/#wcorg-session-4139 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. |
| 21 | | |
| 22 | | ---- |
| 23 | | |
| 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_`. |
| 29 | | |
| 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. |