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

WordPress Trac noreply at wordpress.org
Wed Nov 29 17:28:52 UTC 2017


#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 glueckpress):

 @GregRoss While I’m not qualified to comment on technical aspects, I’d
 like to weigh in on this statement:

    the only real con being some additional work associated with
 translate.w.org

 Fwiw, that’s an over-simplification. We already have a precedence for what
 it means when language files get multiplied. Ask translation teams who
 manage default and formal variants of their languages.

 German makes for a proper example at a higher scale here:

 * There’s ''de_DE.po'' and ''de_DE_formal.po''.
 * And then there’s ''de_CH'' and ''de_CH_formal'' (Swiss German) which is
 ~90% identical with ''de_DE'', but still needs to be translated and
 reviewed separately.
 * So the German Polyglots team needs to keep 4 German language files in
 sync.
 * Consistent translation across variants is an expectation not only for
 core, but for every theme and plugin on the repos.
 * This basically leads to a workflow where a person would translate 1
 string and copy it over to 1-3 other open browser tabs.
 * When the string gets reviewed by a Translation Editor and changes need
 to be made, the same 1-3 other locales have to be edited accordingly.

 While German might be an edge case scenario, it helps understanding the
 non-technical (i.e. human-related) implications of an approach that would
 multiply language files:

 '''Keeping multiple translation files harmonised not only means an
 ''exponential'' increase in work load for experienced translators, it also
 puts a higher threshold in the way of new volunteers.'''

 Probably every Translation Editor on the Polyglots team can tell you about
 the challenges when it comes to onboarding new translators. Making these
 challenges even bigger by doubling-up their work load would likely do a
 bad service to the adoption of the WordPress platform globally.

 While every approach will increase workload for translators, because
 certain strings need more than 1 translation, Yoav’s proposal seems far
 more scalable for Polyglots teams.

 Needless to say, I applaud this initiative of moving a chronically
 neglected topic forward! Getting a minimum viable solution into core is
 key, in my opinion, and I’m incredibly excited to see this being taken on
 and being discussed by the i18n developer community.

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


More information about the wp-trac mailing list