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

[WordPress Trac]

#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:
-------------------------+------------------------------

Comment (by GregRoss):

 I'd suggest a different approach to the implementation, instead of using
 the gettext plural field, use gender specific gettext files, one per
 gender.

 For example gender-female-fr_FR.po, this has several advantages:

 - No need to alter translation applications, use GlotPress, POEdit or any
 other standard gettext tool as there is no need to use the plural forms to
 store the gender data.

 - Unlimited types of gender.  At best, using the plural fields in gettext
 will limit you to 6 types of gender, using a single file per gender allows
 you to support any number of genders you want.

 - Load only the gender data you need.  Having separate files allows WP to
 load only those gender translations that are needed instead of loading all
 of them.

 - Simplification of the `_g()` funciton, as it basically becomes a pass
 through to `__()` with a slightly modified $domain string (perhaps
 `'gender-' . $gender . '-' . $domain`).

 - Support for plurals, since the plural fields are no longer being used
 for gender information, they can instead be used for actual plurals,
 making `_gn()` a pass through to `_n()` much like above.

 - In fact pretty much all the translation functions can be mirrored in
 this way so the gender translation API would be on par with the language
 translation API.

 - Support for non-w.org plugins, as they will need to be able to create
 and load their own gender po files, using standard tools makes this easy
 for them.

 - No need for special context logic as standard context comments would
 work.

 The above solution seems like a far more scaleable and maintainable
 solution in the long run and needs no changes to the standard gettext
 files or locales

 However, a few thoughts on the original proposal as well:

 > 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.

 That seems like making English a second class citizen, gender support
 should be for everyone.

 Looking at the code a bit, adding `_g()` to the extraction code probably
 doesn't work as I think you expect it to, as when the extract runs over a
 file it would simply include these strings in to the default language
 extract, which isn't what you want to happen.  You want a separate file
 created with just the `_g()` strings in it, which would require a separate
 script or different logic in the extractor.

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