[buddypress-trac] [BuddyPress Trac] #5887: Custom language file does not load in bp_core_load_buddypress_textdomain()

[buddypress-trac]

#5887: Custom language file does not load in bp_core_load_buddypress_textdomain()
--------------------------+------------------
 Reporter:  r-a-y         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  2.2
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------

Comment (by boonebgorges):

 For the record: this is not a regression in 2.1. What's happened in 2.1 is
 that we've removed the bp-languages directory (because of changes in our
 build script). Removing this directory has made some folks come out of the
 woodwork to note that they had previously been putting their custom
 language files into the bp-languages directory.
 http://buddypress.org/support/topic/buddypress-2-1-bp-language/

 >  never gets loaded since a language file is already in use.

 If I understand the situation correctly, this statement is a bit too
 general. Our recommended practice has been to put a file
 `buddypress-$domain.mo` at `WP_LANG_DIR`. It appears that this will "never
 get loaded" __if WP has downloaded a translation for the same $domain__.
 In other words:

 `wp-content/languages/buddypress-fr_FR.mo`
 will never be loaded if there is a
 `wp-content/plugins/buddypress-fr_FR.mo`

 But if you're using a custom domain, or if WP has not downloaded a
 "canonical" translation, the custom language pack should load just fine.

 > I think it should be the opposite. Custom language files (if they exist)
 should take precedence over GlotPress language packs.

 All this being said, I agree with this statement. As much as I like the
 elegance of your second patch, I think we should attempt to maintain
 backward compatibility with the currently recommended technique of having
 a file directly in `WP_LANG_DIR`.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5887#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac