Non-Roman character named blogs don\'t show in A to Z Blog Listing
Has this been raised before?
Blogs that use non-Roman characters for their names don’t show in A to Z Blog Listing.
I am attempting to make a social networking site in Asia, where are blogs listed that are written in Chinese, Japanese or Korean characters?
Should their not be an ‘alt’ listing for non-Roman and numerical names?
(Of course, smallside issue) does this even effect a blog called ‘1 … 2 … 3′ or ‘911 Blog’ as there is no numerical listing either)
Am I alone at finding Blog Listing a little bit of a weak link in the extraordinary high potential BP?
No, but it’s been well discussed that WordPress and BuddyPress do a relatively poor job dealing with i18n issues.
The directories are due for an update sooner than later, but there are also a lot of variables to consider language wise with what characters will be involved or displayed. I just installed a few language packs on my Windows 7 installation, and my charmap must be 2000 characters big now. There’s no way to include everything as a clickable link for all languages and have it not look like an awful mess.
What is included in the bp-sn-parent theme is a working example of how you can dump out lists of blogs, and how you can use AJAX to filter through the starting letters of them.
just an idea:
why not having the “User-Blogs” sorted by “most popular blogs” like we have “most popular groups” , “most popular members” and “most popular forum topics” ?
Instead of having an alphabetical directory with “A-B-C”-tabs, why not just having the option to sort by “alphabetically”, “newest”, “active” and “popular” ?
That’s a good idea, and very possible to do too.
Well, numericals they sure could add in one column … but I think you are right to just dump the A to Z then.
many thanks for your feedback !
So looking at the current pages “Members” (testbp.org/members) and “Groups” (testbp.org/groups) , I am currently missing the features “newest”, “active” and “popular” at those pages.
We have this at the “Home”-page at the “members column” and also at the “groups column”, but why not having those features also at the “Group”-page and at the “Member”-page ? It would even make good sense there, as the number of listed Groups and listed Members at those pages is much higher.
So maybe you are considering similar stuff for the “Blogs”-page (testbp.org/blogs) ?
A user is rather interested to see “newest”, “active” and “popular” Blogs than a list of Blogs sorted by “A-B-C”. Having a list of Blogs being shown by “A-B-C” as we do have currently, the user needs to walk through a list of hundreds of Blogs in order to find the e.g. “most popular” Blog.
The same goes for Forums (testbp.org/forums): we currently see “6 Popular Group Forums”. Why not also showing “newest” and “active” Group-Forums within those 6 Group-Forums at the top of the page ?
Besides that: give the Admin the ability to make 1 Group-Forum within those 6 Group-Forums to be “sticky” ? See my TRAC-ticket: http://trac.buddypress.org/ticket/1240
Also sorting “alphabetically” just by “paging” would be fine, the “A-B-C”-tabs are not needed after all, as if somebody wants to search for all members starting with e.g. the letter “K”, he just performs a search by entering the letter “K” into the search-box.
BTW: I just tried what I have described above:
I entered the letter “K” into the search-box and searched for members.
The search-result is actually NOT showing members with the letter “K” (member-names showing in the search-result are actually NOT starting with letter “K” and have also NOT included the letter “K” in their name). Is this a bug ???
The search function sucks. It is not sitewide.
As far as I can see, it only search the admin’s blog which is pretty pointless. There are a few sitewide search option plugins.
I have not so I have no idea how well it works. Requires hackery.
well, at least it should list all pople starting with letter “K” when searching for “K” within members…. then we can get rid of the current “A to Z” directories….
The search actually searches all fields of the user/group/blog, and returns anything that is relevant to that item. So if any of my xprofile_field’s have a “k” in it somewhere, it will return me. So in theory, it doesn’t suck yet, it just hasn’t been narrowed down. It’s a blank slate and a starting point to building a better search. Search functions also greatly depend on the goal of the website and what results you’re trying to pull out.
WPMU Sitewide Search plugins currently aren’t for the faint of heart. They take all of your posts/tags/categories for all blogs, lump them into new additional full text database tables, and search those instead. It’s the only real way to do it without a million joins that just wouldn’t make any sense… Problem is you’re duplicating your data twice over into 1 mega huge table, and rebuilding the search index for old posts on a larger website would be an astronomical task that would take days of processing.
@erich73, those are good recommendations for the directories. Put them in a trac ticket as an enhancement for maybe 1.3?
it is currently not possible to select “Milestone 1.3″ within TRAC-ticket-system.
The search is utterly misleading at present. I had to take it off because it is just plain wrong.
One naturally suspects ‘search’ searches the website it is on. Yet, it only search a single blog on that website … is that not true? It does not even search the obvious; ‘users’, ‘blogs’ or ‘groups’, never mind the content of those.
I suppose the WPMU search does not even any the BP tables yet, right? I guess the way is to go via the Google sitewise search hack at present? Not great but at least *something*.
Has anyone tried/hacked Sphider to work on WPMU/BP?
Erich, f you work out how to cut out the A to Z out and instead add a sort, at least, by ‘Newest | Active | Popular’, please let me know.
sorry, I am not a programmer and do not know how to do this.
Just a suggestion:
for the “search-issue”: could you please open a new thread regarding this topic ?
The reference to language packs on Windows is misleading.
It is a shame that there is not better support for other languages than English …
Given the size of the main non-English/Roman script markets, e.g China, Japan, Korea, are Automattic going to include such expansion into their business plan now they have received the big, multi-million dollar funding?
@nonegiven… The short answer is “yes”, but it’s not really an accurate one…
It has less to do with funding than it does with members of those language speaking communities helping us make the software better. I don’t speak any of those languages and wouldn’t know how to accurately setup a development environment to duplicate the scenarios needed to test what’s not working correctly for them. I personally think that i18n and l10n are vitally important, and any kinks will get worked flat eventually, we just need the right people to help iron them out for/with us.
I don’t think it is a problem with volunteers. Automattic could just pay people to do the work, or hold an account with a translation company. It is not as though it is a huge piece of work to upkeep. Look e.g. how Mediawiki or PHPBB handles it. It only account for 10s of kb.
(Actually, in my case, Automattic has recently hired bi-lingual Japanese staff and I will be interested to see how they are used).
The problem of language files seems to be a problem that needs addressed at the core of WP, centralized, made much easier to handle and more effective.
Now that Buddypress is part of the stable, I am hoping it is also developed as an international device. I am glad to read that there is awareness of this on the development side ….
what responses about it do you get back from the main developers?
You must be logged in to reply to this topic.