Haha this is weird.. I was trying to help you solve the problem and googled for the line:
missing `msgstr[]’ section
Came across this post.. I’m glad you found it, because I was about to give up.. Now when I select the language in WPMU it does not seem to work..
Found the buggy lines, kind of weird because poEdit said that I was done translating. Anyway, edited them and now I can easily open it.
Now just finding out why buddypress doesnt copy the wpmu language setting.
These kinds of errors can also be caused by forgetting the variables (%s, %d, %1$s, etc…)
If the original string has those, the translated string must have them also. The numbers in the error messages are which lines in the po file contain the errors. Open the .po in something that has line numbers and see what’s broken in them.
Xevo, it is written: missing `msgstr[]’ and found 9 fatal errors
This means that you forgot to translate 9 strings ! The lines are indicated in the warning.
Sometimes strings have plural form and you did’nt see that beacause the poEdit window is too small by default on his bottom frame…
To be sure, open the po file in a text editor, it’s easier to read and to search the lines (poEdit did’nt search lines). When found the errors, do the correction and save. Open in poEdit and save also to generate a new mo file.
If you need a dutch translation MrMaz just send me the translation file and I’ll be happy to translate it for you!
french version is avaible here
Some files have been modified to allow translation and the .pot file is also a bit modified (due to missing strings at this time) from the original file in 0.1.1
@21cdb:
Thanks for the kind words!
There is another developer, GIGALinux, from #buddypress-dev that is working on a German translation already! Maybe you can contact him and work on it together?
Also a word of caution that this plugin is still in heavy development, so please don’t put your reputation on the line with it yet! I do plan to create different branches if development could introduce instability or backwards compatibility issues, so you are probably safe from a theming standpoint.
If you find any layout or CSS issues while theming, please let me know so we can make improvements!
Translation is actually not working with your locale function “bp_links_load_textdomain()” in bp-links.php line 138
Instead of the function, a simple if statement is enough and works
if ( file_exists( WP_PLUGIN_DIR . '/buddypress-links/languages/buddypress-links-' . get_locale() . '.mo' ) )
load_textdomain( 'buddypress-links', WP_PLUGIN_DIR . '/buddypress-links/languages/buddypress-links-' . get_locale() . '.mo' );
If you wanna translate:
Erase (or comment) the function and use the code above instead
Name your .mo file buddypress-links-xx_XX.mo (xX are your country code)
Hi, if you send me (arjdan@gmail.com) the pot file I’ll make italian translation for your link plugin.
Thanks
Daniele
JJJ,
I read your post about i18n, and followed it to the letter 
Thank you for saving me the leg work.
Every string is already in the text domain ‘buddypress-links’ (great minds think alike). I guess it must be up to the translators to use their translation tools in a way that avoids duplicate work, because it seems like a tall order for a plugin developer to monitor which strings are duplicates and constantly add and remove strings from their custom domain as the parent plugin changes (in this case BuddyPress and WordPress).
I really need to read up on this, lol.
-M
MrMaz, if you need help getting your plugin i18n friendly, let me know, I’m happy to kick through the code and clean it up.
Basically just make sure all of your text uses a textdomain like “bp-links” or “buddypress-links” then use a program like po-edit to comb through the source folder and it will sniff the strings and compile them into the po/mo/pot file.
Textdomains are important because if you use “buddypress” for your textdomain, and the buddypress-en_US.po/mo file doesn’t have a translation for it, it won’t get translated. It’s important to use your own. The only reason NOT to use your own is if the string matches EXACTLY the BuddyPress or WordPress strings already.
@Chouf1:
I am happy that you are interested in helping with the translation of BuddyPress Links. I am new to i18n and I want to make sure I am doing it right.
I have a .pot file, but many of the strings are the same as the ‘buddypress’ text domain. Is there a way to avoid this when generating the .pot file, or do the translation tools automatically ignore these overlapping strings?
I would like to send you the .pot file so you can go over it and give feedback, what is the best way to get you the file?
Hi, great work !
Is it possible that you provide a .pot file for further translation work ?
Found out how it works in poEdit, this’ll make my job easier.
Instead of the full 100%, I only have to do about 30% translation.
If you need any help translating let me know, I’ll be glad to help I also have no idea how the translation stuff works, but that shouldnt be so hard?!
It has both his po and mo, so what do I do now? I’m new to translating. And since I’m also planning on translating both bbpress and wpmu. I’m eager to learn.
And btw, I also use Poedit.
@xevo
If the dutch language pack comes with both po’s and mo’s, then you can rescan the buddypress directory with poedit, update the database from the source, and then proceed with your changes.
If not, then you’re sort-of out of luck I think. I haven’t found a tool to merge an existing mo into a new po, so it would be a manual process of copy and pasting each preexisting translation.
flyout menu problem is solved.
Was a f… folder permission…argh…
Thxs !
no it’s not a big issue, just a important little detail as any other usability indication – not all site admin read and understand correctly english warnings or message. But you’re right, it’s not a big issue.
I hope you find the time to take a look for the variable problem.
If you know about css problems, i also have trouble with the flyout part of the ‘MyBlog’ menu (is not appearing)
Cheers !
The text “The default theme for BuddyPress” cannot be translated as it is in a .css file. As only the site administrator will see that text when they activate the theme, is it a big issue? The other text here is part of WordPress.
The wrong path thing is more interesting and there are some other forum posts here with that problem. I don’t know when I will get time to look into it so maybe someone else can help.
Hi
I’ll check this out after work.
I’m currently working on a user language setting for BuddyPress that will take on not just user settings but assist in translation for user to user interaction. There are lots of places where BuddyPress might not be completely internationalized, and the most likely cause is probably attributed to the developers and contributors so far being primarily native English speakers.
It’s hard for us to test different languages since we don’t understand the languages we’re looking at or reading or what they’re supposed to look like. We’re relying on the qualified multilingual developers to help us track down and fix the areas that could use the attention.
My current focus is on the English to Spanish side of this, with Portuguese next on the list. I’ve briefly tested the display of Chinese and French but admit that I understand those languages much much less.
I read a few weeks back there’s a plugin out there that’s starting to help out with the translation and language barrier. I hope that as more and more people start using BuddyPress that more people also help contribute to internationalizing it.
Not sure if this needs a separate thread, but as it is connected to the original post:
I have spanish speaking users and have uploaded the spanish Buddypress translations.
However:
– The buddybar follows the language settings of the blog it is on, not of the user that is logged in. Meaning that a Spanish speaker (with language settings -> Spanish on their settings) will see a nice Spanish buddybar when on their own blog, but when they go to an English blog (the main blog for example) then the buddybar turns to English, even though it is ‘their’ buddybar, with their blogs and links to their profile etc. Is this by design or a bug?
As the community homepage is almost separate from the main blog, it should follow the user-set language as well when loaded.
– As the translation is available, I think the language of the main blog/home theme should change according to the (logged in) user visiting it, else they are lost on the community homepage. However, currently it sticks strictly to the language settings of the main blog.
update: just created ticket: https://trac.buddypress.org/ticket/1245 but would like to hear your thoughts on this as well.
Cheers, Harry
