Skip to:

[Resolved] Output of bp_get_options_nav not translating

  • Prometheus Fire


    So I’ve followed all the directions of translating labels to something else. In this case, we are changing Friends to Connections.

    Throughout the site, the change is working except in one instance and that is with the output of of bp_get_options_nav(). This is the subnav menu on the user profile page. It translates correctly in all other areas of the site, just not here.

    I inspected the code for this function in bp-core-templates.php and it isn’t straightforward to me what might be causing this. I noticed that there others have had issues with this in the past (there are a number of threads on this topic in the localization forum), but I’ve been unable to find a solution for this.

    Has anyone seen this issue and solved it? I’m considering adding a bug ticket in trac, but I want to try to solve it here first.

Viewing 6 replies - 1 through 6 (of 6 total)

  • shanebp


    Are you sure you’ve translated this label: Friends <span class="%s">%s</span>

    Did you include this Sources Keyword when creating the translation .mo in poEdit: _x()

    The Friends label is generated by __() and _x(), depending on the context.

    More info re keywords:




    this is obvious, but unfortunately despite your details, difficult to help out, because you don’t tell which code is concerned… or what you used to do your change. šŸ˜‰

    Generally, when it doesn’t translate, it’s because a typo error. A custom function, a theme using outdated strings and a lot of little details like missing dots, comas or percent sign.

    Here some tricky examples which can produce a missing translation.
    Original code looks like this:

    %d friends
    Activity feed for %s's friends.
    Friends <span class=\"%s\">%s</span>

    If %d is typed %s, or if the end point after friends is missing or you forgot to anti-slash or a double cote in the html, gettext mismatch the source and the translation and doesn’t execute it.

    First thing to do in your situation, is to compare what is in your po file to what is in the BP code. Assuming BP code is the master, and always right. Po can be wrong: old version, manually modified, corrupted. Po must in any case be saved as text format in utf8 without BOM. This is invisible, but a real source of issues, specially when anything seems the same and desperatly stays untranslated/unmodified.

    To do this, open the po in a text editor. Search for the string, check the file position given above the string, and read carefully and triple check, that the original BP code and the string in the po are strictly identic.

    If nothing found, ensure there is no custom function somwhere, or a theme playing around the buddybar or subnav.

    Prometheus Fire


    @shanebp and @danbp thank you for the replies on this. I did my change of this using Codestyling Localization. That didn’t work (it worked everywhere but in the subnav). Then I manually created po/mo files and it also worked everywhere but in the subnav. When I did that translation, I created the po using an online po edit (I don’t remember which one, and it certainly didn’t say anything about source keywords).

    I’ve now installed a copy of PoEdit on my pc and am working through the file now, with the keyword information mentioned in the link above.

    I have a couple additional question though, because I’ve found conflicting information on the internet and following the instructions from the BP documentation doesn’t seem to work right.

    The buddypress-en_US.po and files need to be in which folder?

    The documentation says to put them in /wp-content/languages/plugins/ however, sources I’ve seen elsewhere say to put them in /wp-content/languages/ – currently neither of them work for me, but I’m starting this translation from scratch now and I want to get it right.

    Also, does the language define statement in wp-config.php need to be set for this to work? Keep in mind that I’m not doing a full on translation, just this BuddyPress translation to change Friends to Connections.



    – keep in mind that Iā€™m not doing a full on translation, just this BuddyPress translation to change Friends to Connections.

    you put only those strings into your custom po. If the concerned string is on a template file, you can also hardcode it there, and use a template overload to get in from your child-theme in that case. So you haven’t to struggle with poEdit. In this case also, you have to take care of the details given by @shanebp.

    – does the language define statement in wp-config.php need to be set for this to work?

    This is no more used since WP 4.0. You can remove it.

    – buddypress-en_US.po and files need to be in which folder?

    /wp-content/languages/plugins/ (the po file is not used by gettext, it’s only a human readable work file – you can store it elsewhere if you want. You just have to remind where in that case šŸ˜‰ ).

    if you put it in /language/ (of course you can), you will see buddypress-en_US as a language setting. Which is of course not the site language.

    But in any case, keep a copy of your work in a safe place outside of WP.

    Prometheus Fire


    Right, so the advice from @shanebp worked.

    As I mentioned above, when originally did the translation, I didn’t use Poedit, I used an online editor (after using Codestyling first). Turns out the they simply aren’t as advanced as Poedit and those source keywords were really important here. As I was going through the strings in Poedit, I was seeing strings I had never seen before in the other software since the other editing softwares probably couldn’t read the strings in the first place.

    I’ve seen various threads where other people have struggled with translating the same thing. Perhaps an update to the documentation including information about these specifics might be helpful for other in the future. The documentation does talk about using Poedit, but leaves out those rather important details needed to get a complete label and message change.

    Either way, this issue is resolved.



    Glad you got it !
    And feel free to edit the codex page and add your experience and how-to story.

    Participate and Contribute

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘[Resolved] Output of bp_get_options_nav not translating’ is closed to new replies.
Skip to toolbar