Namespaces

Can anything be done about the mighty space left at the top of the profiles now? I'm not a template master... Hill's better at this.

Wow, the screw up in the Recent changes box on the forum index involving namespaces and not including them in the pages listed is starting to be a royal pain in the <>

Mikeeeeee, we need your coding expertise here!

In the past we haven't used namespaces, so the recent changes code generally ignores them - unless a recent change lies within certain types of namespaces, in which case those are handled specially.

Would it be possible to provide more detailed info as to what the problem is, how the list should behave etc.?

The namespaces we are using:

• Help
  
• Profile
  
• Portal
  
• Young Composers (Project pages)
  

The url structure for a namespace is namespace:page_name

When someone edits a page that is a namespace, it "does" gets displayed in recent changes, however it does not link to namespace:page_name, instead, it will link to page_name, which is wrong.

as I go through the dozens and dozens of broken redirects that stemmed from the movement of all the profiles to the Profile: namespace, I began to wonder. Does the fact that the pages are now named "Profile:Person Name" instead of just "Person Name" in any way affect search engine "visibility"? Since it's titled "Profile:blah" instead of just the name itself, would Google/etc. treat is as a non-direct match?

Also... *sigh* ... is there any way you can script all profiles to be redirected to from all pages of the same name without the Profile: bit? So... if you type it "Micheal Porcaro" it automatically goes to "Profile:Micheal Porcaro" without having to create a redirect for him/you. That way we don't have to create redirects for each and every one of the profiles manually(ones that have broken redirects and not)

This might be a pain, with the namespace, because users will want to find their profile to update, and search "My Name" to find that it doesn't even exist. Anywhere. It's gone. And they won't know to search on the profiles namespace... they're noobs. I still hate this whole namespace idea. Unless you can make fixes for these little issuous bits.

The namespaces make sense. As the wiki gets larger you will thank me. Profiles are not articles, and should not be categorized as an article. It does impact search, since the profiles have moved pages, however the colon is a delimiter in Google's eyes, and Google will reindex all the profiles without a problem.

Also... *sigh* ... is there any way you can script all profiles to be redirected to from all pages of the same name without the Profile: bit? So... if you type it "Micheal Porcaro" it automatically goes to "Profile:Micheal Porcaro" without having to create a redirect for him/you. That way we don't have to create redirects for each and every one of the profiles manually(ones that have broken redirects and not)

I don't know how to do this. If you check the profile page though, you will see the words "Profile:" are already defaulted in the text box. This, along with instructions, should be good enough.

And they won't know to search on the profiles namespace... they're noobs.

The input box extension should take care of this. You can embed the input box on the profile page. Maybe we can even embed the "A-Z" nav bar or something?

I just marked all forums as read so I no longer have any MW recent changes on the forum index. Please could one of you produce a list of a single recent change from each namespace? I can then look them up in the database and modify the code to account for them.

EDIT: Actually, is it just a case of the namespace prefixing the recent change entry? So Profile:, Help: etc. I would like to make sure with you wiki demi-gods before I change anything.

I think you may want to refer to this. Is that what you mean?

Yes, just wanting to verify a namespace in this context is a prefix delimited by a colon. So "Namespace:ArticleTitle". Armed with this info, it shouldn't be difficult to make the changes.

Yes, it is delimited by a colon.

OK, everything except Portal should be accounted for. I didn't find any instances of that namespace being used - if I am mistaken then do point one out. Otherwise, we can start supporting it once it springs into use.

What's the status of this dark brown box showing users browsing the wiki? There are numerous problems remaining with it as far as I'm concerned:

• Guests should be hidden - users are not interested in them
  
• Country info should be hidden - potential privacy violation
  
• Should not be right-aligned
  
• Should be labeled somehow ("Users browsing the wiki" would be a start).

I am unsure how to even edit this extension. I have no idea how to only show members. I can span it the entire width, but placement is not easy for this thing.

You can't just put a div around it and cart it around willy nilly?

If you can figure out how to make it display only registered members, I'm sure you could then easily make a toggle "Display Guests" on/off. I really like peeking at what guests are reading so I can make sure those articles are up to scratch and also what articles to bring more attention to.

No way to change the title on a namespace. But I don't mind the profile being there, mainly because we can distinguish between a historical person, vs a YC member. Also, it will filter the "article search" to only search for articles. I don't find it particularly useful to include member profiles as a part of the internal wiki search.

I know that within the last two years, on Wikipedia, they somehow figured out how to get a lowercased first letter in the title (even though the article name and URL still uses the uppercase), via a template. (Previously, said template was just a "technical restrictions" message.) Maybe it'd be possible to make changes on-the-fly to titles via whatever technique they used?

Although, then again, it might be more trivial to do case change than taking a substring... Parser Functions aren't exactly a full-featured scripting language.

EDIT: BTW, you could probably get a bot to fix double redirects. Someone just needs to download and configure a MediaWiki bot for it.

... that could be your job. (the bots). Only Hill and you and possibly Chopin would know how to do those things. oh and hey, welcome on the team, I did NOT expect you to volunteer! :D

I'm actually clueless about bots. I could figure it out over the summer maybe... weekend side-project.

Haha, thanks, glad to be here. x3 Why are you never on Trilly nowadays, btw?

Misha explained how bots work in a PM to me. I figured I would share this:

While the compatibility question waits on the queue, describing how wiki bots work is something I can do.

They log in with a pair of username and password and store the received cookies, which allow them to identify by resending them while interacting with index.php and api.php. There are also other parameters to be kept an eye on, and the preferred communication method is POST. Apart from that, they appear like but simple users to the Wiki software. Now, Wikipedia projects have GZIP compression allowed and it is default for my bot, but I switched it off and it still didn't work here.

The process of logging in is the following, for a Wiki:

1. Password and username must be encoded

2. A connection to api.php should be made (URLConnection object in Java)

3. Now is the time to set up GZIP compression and other protocol-related stuff

4. We start the output for the connection (POST method)

5. We send logindata, like

action=login&lgname=username&lgpassword=password&f ormat=xml

6. We flush the output.

7. We read the response. If it contains the word "Success", we made it.

8. Now we read and store cookies that our connection might have collected during the process. We will have to resend them every time we identify as this user.

That's quite it. Right now I am busy on the WikiMedia issues but I will come back to this once I have finished there.

Sincerely,

M

Login wasn't really an issue... (Definitely want to keep separate accounts doing bot-work. Easier to manage, less damage done/easier to deal with if one of them should be compromised or go haywire.)

I was wondering more about configuring a bot to correct double redirects (some of them probably can do that as an option), or even going through redirect pages in the User: namespace and doing auto-corrections if it can find them. (Haha, that'd be a whole-weekend coding exercise at my level, probably... if the bot supported custom scripts.)