[wp-trac] [WordPress Trac] #42725: Allow gender specific translations

[WordPress Trac]

#42725: Allow gender specific translations
------------------------------------+------------------------------
 Reporter:  yoavf                   |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  I18N                    |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------------------

Comment (by vslavik):

 Poedit developers here. Allow me to provide what is somewhat outsider
 perspective — that of a mainstream gettext user. I know `makepot.php` is
 used internally in WP, but there is sizeable community of WordPress users
 that extract strings using GNU gettext's `xgettext` instead (either via
 Poedit or from CLI) and I think it's worth nothing how this proposal
 affects them:

 In short, the ''standard gettext'' approach would be as mentioned in
 comment:8 — that is fully compatible with the rest of the gettext world
 and is in fact using it as gettext is meant to be used. In comment:9 this
 is criticized as causing translation files explosion, but that doesn't
 have to be. Part of gettext (which, I'm aware, WordPress doesn't currently
 implement, and even chooses to use non-standard `_formal` suffixes
 instead) is cascading lookup of translations. Suppose the language is set
 to `de_DE at formal`: then the runtime is supposed to look for the
 translation in multiple files, in order, until the first hit: first
 `de_DE at formal.mo`, then `de_DE.mo` (for where formality doesn't matter to
 the string) and lastly `de.mo` (for where the country doesn't matter)
 files (I'm simplifying the actual names WP looks for for the sake of
 illustration here). So in a typical case, there could be a complementary
 `de at male.mo` and `de at female.mo` pair with just the few differing strings.

 From the perspective of `xgettext` user, the old `_g()` proposal is worse
 than the above ideal (which I suspect is unrealistic to achieve in the WP
 context) because no standard tool can parse it. But it's not terribly hard
 to extract with a bit of custom code.

 What I understand to be the current proposal, with an optional options
 argument (presumably a dictionary of some sort?) is the hardest thing to
 handle with an external parser. Most extraction parsers, such as
 `xgettext`, don't parse the full (PHP) language, but only look for
 "interesting" fragments — sub-grammars if you will. Something as
 syntactically complicated as a free-form(-ish) options argument is going
 to be a PITA for non-`makepot.php` tools.

 Finally, regarding comment:7 about not wanting to make English second-
 class:
 > > 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.

 Let me just point out that all the proposals above already fully provide
 gender support for English with no need to change the gettext functions
 API to have more arguments (which would again make it very hard for tools
 to extract). You can have — and people often do, for non-translation
 purposes -- an ''English'' translation file too. So it's entirely possible
 to have gender-neutral strings ''in the source code'', as is done now,
 while still providing gender-specific strings for English inside
 `en(_US).mo`.

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