[wp-trac] [WordPress Trac] #42725: Introduce gender compatible translation function, and gender user profile field
noreply at wordpress.org
Tue Nov 28 12:52:02 UTC 2017
#42725: Introduce gender compatible translation function, and gender user profile
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
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
- 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
- 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
- No need for special context logic as standard context comments would
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
More information about the wp-trac