Child Translations

[sooskriszta]

Every once in a while someone asks on the forums how to rename BuddyPress components: Perhaps someone wants to rename Groups to Schools or Majors or Study Groups. Or maybe someone wants to rename Friends to Mates or Connections.

Our stock response is to ask them to edit/create the language files: ​http://codex.buddypress.org/getting-started/customizing/customizing-labels-messages-and-urls/

This is a workable but deeply unsatisfying solution. For one it takes a LOT of work to find and rename each reference to the component name individually in POedit. More importantly, all the changes would be wiped off upon updating BuddyPress. Further, if someone is using BuddyPress in a non-English language, then they basically have to edit the language file which faces the same overwriting issues.

So, what I propose is this:

A while ago WordPress implemented Child Themes. This has been an immensely successful initiative. We could take inspiration from that and introduce Child Translations.

Essentially, the site admin can create a language file containing ONLY the strings that are different on his/her blog compared to standard version of the translation. This file is placed in /wp-content/languages/child/ or something to that effect. When BuddyPress loads translations, the ones in the file in the child subfolder takes precedence over those in languages folder....so strings present in the child subfolder mo are loaded from that and the rest of the strings are loaded from the languages mo. When translations are updated the languages mo is overwritten with a new version, but it doesn't matter as the child mo still outranks it.

This will allow people to not only change component names, but also experiment with other parts of the program.

[slaFFik]

I guess this task should be created in WordPress trac, not BuddyPress.

[DJPaul]

I'm not sure if this is a great idea. It could end up with people with out-of-date translation files wondering why not all of their site is translated, or why something is no longer translated after they've updated to a new version (because we changed a string).

Changing the component names / URLs / slugs, and how hard it is to do that currently, annoys us just as much as someone who is trying to customise BuddyPress for a particular project or for a language. We (specifically, JJJ) is working on it. I don't know for sure if we'll get any progress made on all of this for 2.1, but if we don't, I suspect we might decide that this becomes the main purpose of the focus for 2.2.

Leaving open as I'd like feedback from others.

[sooskriszta]

Replying to DJPaul:

It could end up with people with out-of-date translation files wondering why not all of their site is translated, or why something is no longer translated after they've updated to a new version (because we changed a string).

I concede. But that's still better than losing the custom translations on updates even when strings are not changed, simply because there is no way to separately make or track the few strings...changes need to be made in the big main .po (and .mo) file.

Replying to DJPaul:

Changing the component names / URLs / slugs, and how hard it is to do that currently, annoys us just as much as someone who is trying to customise BuddyPress for a particular project or for a language. We (specifically, JJJ) is working on it.

Where can we track and participate?

[sooskriszta]

P.S. Just created ​https://core.trac.wordpress.org/ticket/28537 Let's see what the WordPress folks have to say about this.

[sooskriszta]

Replying to nacin:
​https://core.trac.wordpress.org/ticket/28537

This is already doable using the existing APIs. If you call load_*_textdomain() a second time for the same domain, it'll overwrite the new strings on top of the initial strings. This mo file only needs to include a subset of strings you wish to overwrite.

I don't think it makes sense for this to be done automagically. It's a lot of extra file stat calls for fairly little benefit. But it'd be a cool, easy plugin.

[DJPaul]

I agree with Nacin's feedback on your WordPress core trac ticket. If you strongly feel BuddyPress should have this built-in, I'd suggest building a plugin, get a lot of people to use it and get their feedback, and if there turns out to be demand, we can take a look and consider if we'd want it in BuddyPress.