meta user
network profile
| bio | website | vyznev.net |
|---|---|---|
| location | Helsinki, Finland | |
| age | ||
| visits | member for | 1 year, 4 months |
| seen | 4 hours ago | |
| stats | profile views | 95 |
I like programming in Perl and C. I know Java and PHP too (I'm a MediaWiki developer), but I can't really say I like them. I keep meaning to learn Python some day, but never seem to get around to it.
I'm working on a Ph.D. in biomathematics. I also like programming puzzles and cryptography.
Please consider any (original) code I post to Stack Overflow (and other Stack Exchange sites) to be released under CC-Zero unless stated otherwise. You may do whatever you want with it and don't have to credit me in any way, although of course that would be nice.
|
May 16 |
answered | Using Extension:Maintenance to generate sitemap MediaWiki |
|
May 16 |
comment |
www.*.us.com not being indexed, but *.us.com is on Google Webmasters @Ojal: That's because it is a subdomain of us.com, which is owned by the company that sells the subdomains, CentralNic Ltd. It's not a top-level domain, although it looks confusingly like one. The actual ccTLD for the United States is just .us. |
|
May 14 |
revised |
Mass Deletion of Spam Revisions in Mediawiki tested, works |
|
Apr 23 |
comment |
How do I transition to SSL without affecting PageRank? @Nick: Would it really be 95%+? I can see that fraction of all your requests coming from Google, but surely the percentage must be a lot lower for logged-in users? That said, I do agree that a full second of extra latency does start to qualify as "painful". (You could solve that issue, and improve your latency in general, by having a bunch of geographically scattered front-end proxies, but that might be going a bit outside the scope of the question here... still, it works for Wikipedia.) |
|
Apr 23 |
comment |
How do I transition to SSL without affecting PageRank? @Nick: Would the delay from redirecting logged-in users from HTTP to HTTPS with a 302 really be that "painful"? It's just one request: with a reasonably efficient implementation, we'd be talking about a few hundred milliseconds at most, even from here across the ocean. Not that I think there's anything wrong with your current plan, just asking. |
|
Apr 17 |
answered | Google alert on native search page: The site may be compromised |
|
Apr 8 |
revised |
Mass Deletion of Spam Revisions in Mediawiki added 324 characters in body |
|
Apr 6 |
revised |
CNAME: does a cname change the url that the browser displays? fix the RewriteCond so it matches (only) "fr.somewhere.com" |
|
Apr 6 |
answered | Better Image Hosting for MediaWiki |
|
Apr 4 |
comment |
Forwarding non-www domain to other domain with dns What's wrong with it is that, as far as browsers and search engines are concerned, those would be two completely different domains with (assuming no funny webserver tricks) the same content. Of course, you can first use a DNS CNAME to make your old domain an alias for your new one, and then configure the webserver at your new domain to HTTP 301 redirect any requests for URLs on your old domain to the new one. |
|
Mar 30 |
comment |
Google indexed URLs both w/ or w/o trailing slash +1 for mentioning 301 redirects, which really are the correct tool to use in this case. Using rel=canonical links will work too, but they're less efficient and less widely supported, and should generally only be used in cases where 301 redirects are not practical. |
|
Mar 30 |
revised |
What are my options when I want to restructure mediawiki content added 621 characters in body |
|
Mar 30 |
answered | What are my options when I want to restructure mediawiki content |
|
Mar 29 |
comment |
Multiple IP addresses to a server That's a good point. Depending on circumstances, you might be able to use wildcard and/or SAN certificates, which are supported even by IE on XP, instead. They do have some limitations compared to SNI, but those aren't too serious unless you're planning on running a shared webhosting service or something. (Wildcard certs only apply to subdomains of a single domain name, and SAN certs need to be reissued every time new domain names are added to the server.) |
|
Mar 29 |
answered | Robots.txt vs Sitemap — Who wins in a Conflict |
|
Mar 28 |
comment |
Multiple IP addresses to a server Note that the article was written in 2009. Most of the "new browsers" it lists have been obsolete for quite a while. |
|
Mar 24 |
answered | Mass Deletion of Spam Revisions in Mediawiki |
|
Mar 1 |
comment |
Redirect from the main page on multilanguage site (continued) Anyway, as for search engines, the whole point is that it shouldn't matter all that much which version they see first, as long as you provide rel=alternate links so they can find all of them. Even dumb search engines who don't understand rel=alternate should be able to find all the versions just by following the in-page interlanguage links (which you of course need to include for the users anyway; although perhaps that is not quite so obvious that it need not be mentioned). |
|
Mar 1 |
comment |
Redirect from the main page on multilanguage site @GDav: I'd guess Accept-Language should be a fair starting point; some users do set it, and even for those who don't, it's likely to default to the OS language, i.e. something the user likely understands at least a little. But I don't have any personal experience with that, so I can't really say anything very useful about the details. FWIW, Google itself seems be using geolocation; my Accept-Language lists only English, but google.com redirects me to google.fi. |
|
Feb 26 |
comment |
Redirect from the main page on multilanguage site @GDav: AFAIK, redirecting users from a language-ambiguous URL (e.g. http://example.com/) to a language-specific URL (like http://example.com/en/ or http://example.com/fr/) should be fine, as long as those pages don't try to redirect the user further (i.e. a user going directly to http://example.com/fr/ should get the French version, no matter how convinced you might be that the user doesn't really understand French). |
