[buddypress-trac] [BuddyPress] #4857: Automatic download of translations from translate.wordpress.org

buddypress-trac noreply at wordpress.org
Thu May 23 18:00:00 UTC 2013


#4857: Automatic download of translations from translate.wordpress.org
-----------------------+-----------------------
 Reporter:  DJPaul     |       Owner:  DJPaul
     Type:  task       |      Status:  reopened
 Priority:  normal     |   Milestone:  1.8
Component:  i18n       |     Version:
 Severity:  normal     |  Resolution:
 Keywords:  has-patch  |
-----------------------+-----------------------

Comment (by johnjamesjacoby):

 Replying to [comment:21 boonebgorges]:
 > I can't speak to the scaling issues of GlotPress and the wordpress.org
 infrastructure, but they sound like serious issues. At the same time, I
 can't help but feel disappointed and frustrated that these points weren't
 raised earlier. DJPaul's initial patch for this ticket, which demonstrated
 the basic method, was posted here months ago, and progress on the ticket
 has been announced publicly many times in dev chat and on bpdevel.
 I understand and share your sentiment. We've improved our peer review each
 release, and this one was missed until the very last minute.

 > Responding to nacin re `load_plugin_textdomain()`. I think the reason we
 haven't used it in the past is because we don't ship our translations
 along with BP, and we actively encourage people to store them in wp-
 content/languages. `load_plugin_textdomain()` with its deprecated
 $abs_rel_path param, does not make it obvious how to support this setup. I
 could only make it work by walking up the directory tree in
 $plugin_rel_path. See 4857.05.patch. Am I right that this is the only way
 to make `load_plugin_textdomain()` load .mo files from wp-
 content/languages?
 You're correct about this being the reason why, in addition to us wanting
 to control the ability to both have an external mo file in wp-
 content/languages, and eventually bundle them in core (per this ticket.)

 Nacin: Would calling the 'plugin_locale' filter in our own function
 suffice? If not, it looks like load_plugin_textdomain() would need a patch
 to support using the /wp-content/languages/ path, either to un-deprecate
 the $abs_rel_path argument, or add a 4th parameter to assume that path by
 default.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4857#comment:22>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list