Talk:Www.wikipedia.org template/2009

From Meta, a Wikimedia project coordination wiki

Smaller Wikipedia picture files

I have compressed the Wikipedia header and the book images saving about 4kb. Could a sysop please update the front page. Please see the current discussion at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Smaller_Wikipedia_Logo_files Thank you in advance.Smallman12q 01:47, 22 February 2009 (UTC)

Thanks for optimizing the images. I've updated the portal to use your images, except for the project logos, where the dimensions don't match. – Minh Nguyễn (talk, contribs) 01:36, 24 February 2009 (UTC)

Names on wikipedia.org page

Hi just a suggestion would it be possible to have say the wiki from whatever Country you are logging in/searching from to appear on this page. To encourage users to also check out and possibly edit less often used wikis. I ask this after reading this thread thanks. BigDuncTalk 08:16, 7 May 2009 (UTC)

We would have to determine a county based on the visitor's IP address. The people who maintain this portal at Meta don't have the capability to do this, but you can file a bug at Bugzilla requesting the developers to add this functionality. But I would note that, even when we selected visitors' languages based on their browser language, we got quite a few complaints, because many people prefer the English edition despite their country or native language. – Minh Nguyễn (talk, contribs) 19:09, 11 May 2009 (UTC)

Arabic

According to en:Talk:Main Page#Arabic Wikipedia the Arabic wikipedia now has 100k articles. Nil Einne 08:43, 27 May 2009 (UTC)

Apologies looks like this was already done, I didn't look properly and missed the Arabic wikipedia under 100k. I also noticed that it's possible to do this yourself to the test area Nil Einne 08:53, 27 May 2009 (UTC)

tweaks to the page

There's a discussion at

which will probably be pasted here at some point. I have been making some adjustment to the code as discussed there. Notable changes I have just made include removing the

  • wiki/Main_Page

path form the top-10 and the 100,000+ group. These correctly redirect to the appropriate local page and I plan on doing the others as I check things out. These changes serve to decouple this page from the local details, remove the Unicode which would otherwise be encoded into unpleasant numbers, and reduce the page size. I've been adding stuff, too; mostly titles down at the bottom for the other projects. I've stubbed null-titles on most links and welcome fleshing-out. I'll watch for other comments, too, of course. Cheers, Jack Merridew 10:21, 27 May 2009 (UTC)

Orbiting links

See here. This makes the other bits of text in orbit part of the link. The </a> is moved and there are some other markup adjustments. The net result is fair-sized rectangles that are clickable. The language name gets the underline-on-hover, but the rest doesn't; ditto the link colours. I suggest giving this a few days of browser/platform testing and a time for comments before syncing it live. Cheers, Jack Merridew 14:54, 27 May 2009 (UTC)

  • Really looking for some checking that this is ok on most browsers, especially those from a rainy area. I'm fairly confident that this works widely, but I don't wanna break the main page ;) If there are any issues the redlink below to my userspace will quickly go blue and this will be reverted.
  • http://pruebita.org/cgi-bin/livepreview.py?site=wikipedia — preview the /temp page
Cheers, Jack Merridew 06:26, 29 May 2009 (UTC)
  • This is now live; please advise of any issues. One minor issue I'm aware of is that SeaMonkey 1.1.16 does not properly render the Russian title attribute; the Cyrillic characters come up as question marks even though I have the font. Cheers, Jack Merridew 06:32, 1 June 2009 (UTC)

The change causes a problem on IE6. See the problem report at en:Wikipedia:Help desk#www.wikipedia.org's main page has a text display problem... Specifically the Spanish/German, French/Polish, and Portuguese/Italian largely overlap in the center of their respective lines. See File:Orbiting links on IE6.jpg for how it looks. —teb728 t c 09:46, 3 June 2009 (UTC)

Thanks for the screen-shot; IE6, the bane of the internet. I've posted a tweak to the /temp page that disables the bit I believe is at issue. You can view it in the pruebita link above. It help? Cheers, Jack Merridew 09:51, 3 June 2009 (UTC)
I did some more experimenting on my private copy and found that removing height: 100%; fixes the problem. —teb728 t c 09:57, 3 June 2009 (UTC)
Really? That was supposed to be a nudge for IE6's sake; I'll revert my tweak and drop the height; thanks. Cheers, Jack Merridew 10:05, 3 June 2009 (UTC)
  • I'm on IE6. I feel dirty. And this keyboard is dirty. The fix looks ok, so someone should sync this soon. Ya, other stuff will come along for the ride. All will be fine; this time ;)
    Cheers, Jack Merridew 11:52, 3 June 2009 (UTC)
  • Found an IE8 machine and there's no problem with the rendering of our page. I miss Firefox already. Cheers, Jack Merridew 12:46, 3 June 2009 (UTC)
Done--Nick1915 - all you want 13:08, 3 June 2009 (UTC)

Redesigning

Moved from User talk:MZMcBride#Tidy a design?. --MZMcBride 23:59, 27 May 2009 (UTC)

I made a few tweaks. I'm thinking more title attribute are appropriate — even if they're just parroting the link-text. I also fixed the encoding of the ja:wp url and believe the others should be done, too. Give a nod and I'll work through them.
For wholesale changes, a testrig that allows live testing of the temp page will be necessary. I've not looked through everything in that page but am not worried about it. We will need a group of others involved; any significant change here will require a lot of consensus and a lot of browser/platform testing. What's the ambient view on supporting ancient browsers? I see fixes for IE5 which down to about 0.1% usage.
At first blush, I'd say the general look of logo and top-ten is pretty set; the stuff below may be easier to find agreement on. I don't much like the off-colour book images and am eying the block of links as something that could be nudged along. Thoughts? Know of other interested parties? Cheers, Jack Merridew 09:34, 24 May 2009 (UTC)
Well, I'm in favor of a big re-design, personally. The floating around the globe is antiquated. The little rows of books with all the links under them looks cluttered and amateurish. It was fine for a homepage a few years ago, but we need to look more like it's 2009.

The URL encoding thing, I think there may be a note in the page history about that. (Found it here.) If Mxn is still editing, I'd ping him. As for older browsers, the consensus seems to be this: it needs to not break completely for ancient browsers. That's how MediaWiki is now developed. It doesn't have to work perfectly and have every feature if someone is using IE5/Mac, but the site still has to be usable and can't break completely.

As for advertising, Meta:Babel, Wikimedia Forum, and a few mailing lists should be sufficient (foundation-l, mostly). It's best to make sure we don't get too much bias from a particular wiki.

For live previewing, I made http://pruebita.org/cgi-bin/livepreview.py?site=wikipedia last night (it reads the /temp page). At some point it could probably support /temp_1, /temp_2, etc. to accommodate multiple sandboxes.

--MZMcBride 18:31, 24 May 2009 (UTC)

I've just struck my comment re a testrig and am sorry this led to work for you. I guess I had my head in wiki-preview-mode. I usually edit in an external editor and had saved the page with the clever name of “untitled” — I have since renamed it with an html extension and since all the urls are fully qualified, it works just fine browsing my local copy as long as I'm online.
I'd certainly consider going further than the orbiting links but am sure that some will resist that. That route will involve a lot of talk and sandboxes. The bookshelves do look clumsy and dated. I believe that the convoluted positioning is mostly about getting the images to clip when the screen is really narrow — and it works, but who runs 640px windows? background-image might be a better way to go. I peeked on a handphone using Opera Mini and it doesn't clip; they wrap and the numbers shift off-center.
The URL encoding is wrong and should be fixed. I will ping mxn (whom I don't know). It is a shame that URLs are currently restricted to a limited character set and this will change in the future. The internet will become quite bewildering to a lot of people when entire URLs can use any Unicode character. The primary reason to switch them back to the awkward encoding is to ensure proper accessibility. It's working for me with my browsers (FF, but I have others, too). For some user agents the Unicode will be a problem.
I think the route forward will be two-tracked; tweaks to the temp page that get moved over fairly regularly and some prototypes in sandboxes where more radical changes get tried out. I noticed some missing xml:lang attributes that should be added and think some meta tags should be added; I will stick those into the temp page shortly. I'm also thinking that some of the markup clutter should be reduced with some more CSS; it can go in the head section for now and get moved to a style sheet later. I'll look further into the page history to see what's been going on. It seems to me this page has pretty much been static for years. I'm also wondering how the updates are done (or should be done); i.e. when a wiki moves up due to crossing a numeric threshold. This could be a job for a bot and it might key-off the html comments; some of those have odd spacing in them and I'm wondering if it's from being script-generated.
I'll go slowly for now and will try and come up with an idea or two for a different approach. I'll look at some of the other mul pages and see if there are good ideas out there — although the propagation may well go mostly the other way.
Cheers, Jack Merridew 09:08, 25 May 2009 (UTC)

Hi, would you mind moving this discussion to Talk:Www.wikipedia.org template once you start making significant changes? We can get more feedback that way.

I decoded the URLs to reduce the page size, as you noticed. Actually, I think we should remove the full URLs altogether (so http://en.wikipedia.org/ rather than http://en.wikipedia.org/wiki/Main_Page), as suggested by a user at Talk:Www.wikipedia.org template some time ago. Nearly all of the wikis resolve their main pages correctly. Some lead to redirects, and we can leave those page names in, encoded. A few of the 100+ wikis don't even resolve to the correct page, so we'll need to keep those page names, too.

The portal is completely hand-mantained for now. I watch Wikimedia News and List of Wikipedias for milestones; the latter page is kinda-sorta bot-generated. It shouldn't be too difficult to write a script that generates the portal based on the bot-generated list. I started a few years ago but never kept it up-to-date with the latest portal markup changes. Any script will have to maintain all the idiosyncrasies in language naming and sorting.

Forseti's proposed design

I'm quite in favor of a redesigned portal. The current design was outmoded even before we put it live; many people (including me) were impressed by Forseti's proposal, but it came a tad too late for voting. Wikipedia has by far the most complex language selection page of any major website, so keeping the portal usable for all languages will be a challenge.

Good luck with the overhaul. I'm a bit too busy to come up with a design myself, but I'll try to help out.

 – Minh Nguyễn (talk, contribs) 20:21, 25 May 2009 (UTC)

Hi, and thanks. I'm trying to get up to speed on the issues here. I've given that talk page a first look and will look again. I'm surprised at all the concern about page load times; I'm on a crap connection in the third world (w:Bali) and it loads fast enough. Some of the things I've begun, like adding titles, will push the page size up a bit.
I like the general look of that old prototype and if there's a sense that it's time for something new, great. I had several chats with non-editors who do read en:wp. These are folks wo/bookmarks to site who find things via Google searches and typing www.wikipedia.org into Google toolbar. They both said they didn't like it; said so strongly. One comment was that it was “so plain”.
If things will properly redirect, then dropping the various 'wiki/Main_Page' bits will be good, reduce the page size, and decouple from other sites' internals. Projects that don't have things configured correctly should get a nudge to sort it out. I'll take a poke at this next time I focus here (i.e. tomorrow, but not so much tonight). I'll start with the top 10. One thing to keep in mind with any new design is that we may no longer have a top 10; a 3×3 grid would give us 9; 12 or 15 could happen. I'd like to see a few new features such as expanding the links to fill a larger block; i.e. a fair-sized rectangle containing:
“English
The Free Encyclopedia
2 847 000+ articles”
with all of it clickable. On the other projects at the bottom, this would entail wrapping one links around both the icon and text; eases maintainance and improves usability. I added some more titles and meta tags yesterday; mostly they should be good, but some tweaks may be appropriate.
More tomorrow. I agree this discussion should move over and will leave it to MZMcBride (his page, and all). I would like some feedback on when it would be best to move to a sandbox instead of the /temp page. I don't want someone to have to revert what I've done to updated numbers/stats because there's no consensus for the changes. Moving to a sandbox will likely require pasting whatever delta from the temp page sometime next month. As said above, I'm thinking a two-tier approach; tweaks to the current page while exploring new designs in a sandbox.
Cheers, Jack Merridew 12:58, 26 May 2009 (UTC) (whose real name is David)
I guess the concern isn't that the page is too heavy overall – it certainly used to be – but that, for such a textual front page, it does load slower than it should for many people. Part of that is the sheer amount of markup we use. In contrast, Google has always used HTML 4 and tables in their markup, because every bit of bandwidth matters for them. We're not that extreme, obviously, but it doesn't really hurt to optimize here and there. EVula estimated that we'd save 50 kB just by removing those page titles from the URLs.
When the portal was first rolled out, a lot of people were pleased that it looked so simple, like Google's front page, while a lot of others (including me) were disappointed that it looked so temporary. Either way, we've kept that portal for a few years now, and we've already had arguments about the original design. Up-and-coming editions want to be featured above the fold, but we can't squeeze them into the Top 10 ring without making the design rather cluttered.
One thing to consider as you redesign the top section: we currently sort it by page views. That should probably stay, because there was a very heated discussion and vote last year to change it to that ordering. Whatever you do with the rest of the links, we're all ears eyeballs. Perhaps even display them as a tag cloud of sorts, alphabetically but sized by page views or articles.
Maybe in a few weeks I'll find the time to finally finish that portal maintenance script.
 – Minh Nguyễn (talk, contribs) 22:19, 26 May 2009 (UTC)
I've not come to this with any specific look in mind and have had no epiphanies yet. I tend to be quite severe on questions such as validation and am a bit surprised that Google is going plain html. I see they're omitting quotes on attributes, presumably to save bytes served. They're smart people; I know, I've been there. They do things for reasons with a lot of thought in the process.
I had wondered about the order of things. I still need to give that talk page a more thorough reading. This is sure to have a protracted discussion and any initial prototypes are going to draw opposition. Getting a few more above-the-fold would be good; I saw the talk about zh:wp. Broader issues in play, of course.
Reviewing your tweaks, I've just restored
  • <meta http-equiv="imagetoolbar" content="no" />
as it is for removing the MSIE icons over the top-left of images; this would only be for the logo and I'm not sure what the image size threshold is. It may be only for IE6; I'm mostly on FF/Mac these days. I'll see what I can find about what really cares about what meta-tags. The most important one is “description” and any tool is free to read all the extant tags and do what it will with them.
  • <meta http-equiv="Content-Language" content="mul" />
may need to have the “mul” tweaked; I made that up as a punt. I omitted “keywords” and the others you nixed are minor. The Google bot will be by checking these sites often enough.
I see that most what I've been doing has gone live, so I'll take that as a sign that no one's worried. For the moment, I'm going to stick to tweaks and marinate on future looks.
Cheers, Jack Merridew 07:55, 27 May 2009 (UTC)
As I mentioned in my edit summary, if you search the source for the string "imagetoolbar", you'll find that we've had that tag in there all along, but conditioned so that IE 7+ doesn't see it. Search engines primarily use "description" and a few technical meta tags, like "robots" and "googlebot". Beyond that, browsers like Firefox list meta tags in a Page Info dialog. But that's about it; the vast majority of the Dublin Core goes unused with respect to HTML pages. (Some additional DC properties are used in RSS/Atom feeds, however.)
"mul" is correct: that's the ISO 639 code for documents that consist of multilingual content with no overt bias towards one language. Cbrown1023 pushed your changes live, but I suspect he doesn't realize you've been using the temp page as a sandbox. I'm pretty sure none of the admins here have tested your changes in various browsers yet. (I use a Mac, so someone else needs to test it on IE.) Those changes were non-visual; now that you're stepping into visual alterations (like the larger links, which I really like), we'll have to tread more carefully.
Thanks for all your work so far.
 – Minh Nguyễn (talk, contribs) 17:50, 27 May 2009 (UTC)
I missed the "imagetoolbar" in the IE comments; sorry for the to and fro. I'll review Dublin Core; but am mostly busy today. I tweak the temp page just now to get printing playing nice. I've used this display: block technique many times and know it to work on IE so it's more a question of did I miss anything in this specific case. "mul" was used in the html-element lang attributes, so it seemed like a good punt. Will be sure to tread carefully! (and commenting below) — Cheers, Jack Merridew 03:05, 28 May 2009 (UTC)
Just so you know, it's best not to use the /temp page as a "sandbox". What you use there should be ready to commit at any time. (I did it this time because the Arabic Wikipedians were getting antsy and wanted to be moved up to the 100,000 section. ;-)). With regards to testing on different browsers, see browsershots. Cbrown1023 talk 00:12, 28 May 2009 (UTC)
I will setup a sandbox (/temp/sandbox ?) for substantive changes. The changes that I see as having been synced do not include the large links and some other bits; if anyone wants to revert here I'm fine with it. I'm pretty sure all will be fine and once it's checked-out and live would do the other www.(project).org pages, too. I see my tweaks to quote and news were pushed live. Thanks much for the browsershots link. I've heard of it, but not explored it in any depth; I'll be using it, now. The ar:wp folks should be proud of that; good-on. id:wp was pleased to move-up last year. Cheers, Jack Merridew 03:05, 28 May 2009 (UTC)
How about User:Jake Merridew/www.wikipedia.org template? Since it's in your user space, you don't have to worry about us getting all flustered if you try something new. Hehe, apparently the Arabic community went through such lengths as filing an OTRS ticket asking the English Wikipedia to update their list, too. – Minh Nguyễn (talk, contribs) 05:08, 28 May 2009 (UTC)
Ya, user space makes sense. I noticed a link to that portalpreview.js script and will give it a try; mostly this will be of use to others checking rendering on various browsers/platforms. I'm also wondering if the browsershots folks will take requests for arbitrary links, such as a sandbox. I seem to recall that they want a fee; will have to look... That seems an odd use of OTRS, but it seems to have worked. Cheers, Jack Merridew 09:09, 28 May 2009 (UTC)

There's also apparently a user script to preview the raw HTML: User:Splarka/portalpreview.js. (Cbrown gave me the link.) Smart move removing the /wiki/Main_Page equivalents where possible. What about getting the sister projects at the bottom to line up better? And at some point the large elephant in the room (those awful book icons) need to be addressed. /me resumes lurking. --MZMcBride 04:38, 28 May 2009 (UTC)

As said above, I'll try that script. The sister links will go the same route as the orbiting links — and I do like things to line up nicely. My methods of work tend towards incremental steps; i.e. just keep moving in the right direction. I'll trim more of the Main Page bits as I test; nb: the uk:wp one was wrong, although it still seemed to find its way there. (I just know I'm gonna end up with my account activated on 800 projects;) Anyone floated the idea of just cutting the books? ;) Cheers, Jack Merridew 09:09, 28 May 2009 (UTC)
Have you unified your account using Special:MergeAccount yet? That keeps you from having to log in separately for each wiki, at least.
I guess we could lose the books, though they do function well as a light separator between the different sections. A light gray horizontal line would also do. But it'd be really cool to get a puzzle-piece pattern (without text) to replace the books, repeated the same way. Maybe Commons has something that matches the puzzle ball's color?
 – Minh Nguyễn (talk, contribs) 20:58, 28 May 2009 (UTC)
Ya, I'm active on about 128 wikis. I just don't want to be on all of them without having edited on most of them. When I activate on a wiki, I set things like sig and prefs (like lang). It gets tedious. For checking the remaining redirects, I'll use a different browser that's not logged in. I like the puzzle piece idea; I would certainly not cut the books without adding some new treatment. The first puzzle piece that came to mind was the missing one just above the 'Omega' — while I'm sure that there's a lot of puzzle imagery about, I've not seen any with that idea. See my comment to Catherine, below. Cheers, Jack Merridew 07:47, 29 May 2009 (UTC)

Hi all, and thanks Jack for dropping a note on my talk page about the possible redesign. I came up with the original idea to have the globe and circling top ten, after trying to come up with something that was language neutral, distinctive and recognizable without text, and at least somewhat related to the Wikipedia logo. I'm still proud of it -- this design has represented Wikipedia in newspapers such as the Wall Street Journal, and in the background during TV interviews with Jimmy and others. But if it's somewhat dated now, I certainly have no personal objection to an update, or to a completely new design if that's what the community wants.

The books definitely need replacing -- I'm actually somewhat astonished that they're still untouched. They were a temporary solution for trying to indicate the size of the various editions visually, without using a word for "articles" or "pages" that would need to be translated. When I tried uniform-sized volumes (like a printed encyclopedia) it made a somewhat indistinct rectangle that didn't look much like books, so I quickly hacked together a varied bookshelf, thinking a better replacement would soon come along.

A puzzle piece would look nice visually, and coordinate with the globe; there are numerous variations at commons:Category:Wikipedia puzzle piece icons. I like this idea a lot.

One tangential thought about conserving page weight though -- if we're taking a step away from the meaning of "volumes" or "pages" in the book image to move to the more abstract puzzle piece, we could just as well use any symbol, without needing to load an image at all. Asterisks or bullets or a more decorative Unicode symbol (repeated to indicate size) might load faster.

I really like all the other tweaks that Jack has come up with so far, and agree with the general move to lighten and streamline the page as much as possible. I'll keep an eye on discussion here and comment if I feel the need, but overall I think you have things well in hand. Good luck! Catherine 23:30, 28 May 2009 (UTC)

Hi!. I'm sure that this look has become quite iconic and anything that shifts it much will entail a whole lot of discussion. This is still a small chat. Hoards from en:wp will opine at some point. I reviewed some of the history of the implementation and the books have been fiddled with a bit. However, the design has mostly just adapted to the lager numbers; higher thresholds, more wikis. This has resulted in the page weight increasing, but I don't see that as much of a problem. I'll avoid indenting the code, ok? I'm also keeping print and handheld device contexts in mind. Not many iPhones in Bali, though.
I've been adding title attributes and many are on images. I've been using English on things like the sister projects where there are no lang specific subdomains (meta, commons, species) and just the project name for the others; tweaks welcome. For the images, I'm thinking we should have English alt text and null title text; the alt text is required (and has to be in some language) and null is not good — in cases where the images don't load, whomever/wherever will get the English alt text, but for the normal case they'll get the image and the null title text will give them no title balloon. Right track?
I'm going to continue snipping the /wiki/Main_Page bits in the various language as I check that the redirects from the root work and seem right. Again, I don't see the server load as a problem; someone buy more if it is. This is a gross encapsulation violation and clutters the page up with subdomain-specific detail. And there's the encoding issue. Someday, full Unicode will be fine in urls; we'll change back then. nb: I don't have quite all these fonts installed, although I do install more as I find them. Most people will not have more than their platform's standard font-pack plus whatever came along with major software packages they have. I like the idea of using some interesting decorative characters, but we'll have to be careful; there will be no alt-text to fall back on.
I'm still viewing this as a two-track process; tidy-up this current implementation and extend it in relatively minor ways and to then float a few looks that are significantly different. A lot of the center-line centric (;) look of the current design seems to be about adapting well to most any screen resolution and this mostly works. My phone runs 240×320 and the top-10 drop under the logo in en, ja, de... order; the books don't do the clipping thing at all and look awful, and the lang-link items get the middot on the left, not the right. We can do css rules to fix some of this. I'm using Opera Mini; in non-Mobile View, things mostly work, but there are still oddities and I have to slew about due to the logo region width.
I'd like to keep the straightforward tweaks in this /temp page and use my userspace for the more risky experiments but will scoot right over at even a slight further hint. A lot if this is a reluctance to deal with the inevitable merging of stuff post-fork. I would like to finish sorting various minor nits before a fork. For the sister project at the bottom, I'm thinking of a different markup structure (like a dl) with rules to line things up evenly. I would sandbox-trial this sort of thing.
I expect much of this to propagate to the other project www-subdomains, too; I've an oar in on a few of those so far but have not gotten discussion going.
Cheers, Jack Merridew 07:47, 29 May 2009 (UTC)
I like the current curvy design, save for the limited number of wikis it represents. As Wikipedia grows, the number of world-class single-language sites in the project does as well. I would be quite interested to see a reesign that incorporates more languages, perhaps at different sizes -- but with less of a severe dropoff in prominence from the top-10 to the 11th. 18.85.46.244 23:01, 20 July 2009 (UTC)

Arabic Error

I'm glad to see that the Arabic Wikipedia has reached the point where it now says "search" in Arabic on the homepage, however the Arabic is incorrect. It currently says بحث , which, depending on how you read it is either the verbal noun "search" or the the 3 person masculine perfect, "he searched." In order to make it in line with the other languages that are the second person comand "search!" it should be إبحث . --207.172.145.143 23:35, 30 May 2009 (UTC)

Thank you for your concern. The use of nouns is clearly distinguishable from the context. There has also been a discussion on what form to use on the Arabic Wikipedia and consensus was to use the noun. Also, Google uses the noun form. Regards. --Shipmaster 00:30, 31 May 2009 (UTC)
Actually the use of the nouns is not clear by context considering that in some of the other languages the imperative is used. See Turkish: "ara" (2nd person imperative) as opposed to the verbal noun "arama" or "arayış," or the french infinitive "rechercher" instead of the verbal noun "recherche." There is an obvious inconsistency in the use of nouns. Similarly Google is not the definitive answer on language use. Examine the organic Arabic search engine ابحث.com.--128.8.89.68 19:25, 1 June 2009 (UTC)
The word "بحث" is used on the search button in all Arabic wikis. Changing it here will confuse users. Also, "إبحث" is a spelling mistake. --Meno25 07:14, 3 June 2009 (UTC)
There is an inconsistency simply because they are different communities, each community decides on what best suites them, I am under the impression that you consider all of them as one community of users. The fact is, there are very few rules that the WMF chooses to impose across all wikis, preferring instead to let each community figure out what is best in their specific situation. I should also add that given the above, if you have a suggestion regarding the Arabic wikipedia, your best place to discuss it is on the Arabic wikipedia. --Shipmaster 05:36, 4 June 2009 (UTC)
another ar-issue

I just added dir="rtl” to the ar-label for the search box, which seems just fine to me. We could do this in the actual search box; this would right align that entry, at least in FF. What's the norm here?

Also, the labels for the search box seem to be in no particular order. Is there an agreed order for these? Cheers, Jack Merridew 08:02, 31 May 2009 (UTC)

See the comment just above the label: it's ordered by number of articles, a remnant of the way we used to arrange the top 10 ring. Gotta love design by committee... :^) – Minh Nguyễn (talk, contribs) 02:29, 1 June 2009 (UTC)
Apparently only the Wiktionary portal is commented that way. – Minh Nguyễn (talk, contribs) 02:30, 1 June 2009 (UTC)
Thanks. I've not given them all a close look, yet. As I do, I'll attempt to nudge them to common conventions, including the commenting. I just added 'ar' to the js array (master copy, too). Cheers, Jack Merridew 06:23, 1 June 2009 (UTC)

Interpunct

MZMcBride replaced the bullets with bold interpuncts back in 2007, citing a screenshot (now deleted) of poor rendering in Opera. I don't know if Opera still gives us problems rendering bullets, but you might want to double-check. – Minh Nguyễn (talk, contribs) 19:08, 2 June 2009 (UTC)

I have Opera 9.64 and things look fine. Older versions of Opera have had some issues but they've been sorted out for some time, It's a fine browser, just not my primary one. The other projects are all using the normal bullet and this cut about 1500 bytes of markup clutter; besides, b-elements should be strong-elements and that's just more clutter. The wrapper might be useful if we were targeting it with a css selector, but we're not and I don't see that in the immediate future.
re the other projects; I'm going to keep pushing them in the same direction as this page. For the moment, I'm not going to use the a-element block technique, but expect to. On wikinews, the second link will have to go to do this; a discussion for there. The diffs will look radical, but I'll stick to to straightforward refactoring and mark-up tweaks. I'm being careful. Cheers, Jack Merridew 06:54, 3 June 2009 (UTC)
Alright, if it looks fine in Opera, then I’m glad to see the bullets back. By the way, <b> should only be replaced with <strong> if <strong> is semantically correct: that is, if you would shout the text in question if you were reading the page out loud. <b> and <i> are deprecated, but HTML 5 is undeprecating them, and there are legitimate uses of both. (Especially <i>: "they went <i lang="fr">en masse</i>" is correct; "they went <em lang="fr">en masse</em>" is not.) Since the bullets were completely presentational anyways, there would've been no need for <strong>. – Minh Nguyễn (talk, contribs) 21:08, 4 June 2009 (UTC)

sync needed

Now would be a good time to sync this. It will get ko.wp into the 100 000+ block, and I'm sure they'd like to see it; it will also get a slight further tweak for IE6 in there. The other cuts to wiki/Main_Page type stuff are all fine/tested and reduce the page size. Cheers, Jack Merridew 15:17, 4 June 2009 (UTC)

already done ;)--Nick1915 - all you want 15:20, 4 June 2009 (UTC)
While I was typing, or not refreshing my watchlist. (thanks, too, for the /tt; I don't validate talk page posts;) Cheers, Jack Merridew 15:29, 4 June 2009 (UTC)
lol, np--Nick1915 - all you want 15:39, 4 June 2009 (UTC)

issue with some of the rtl languages

I just noticed an issue with some of the languages in scripts written right-to-left. I started by moving a dir="rtl” from an a-element to a contained span-element here. This ’pedia, ug:wp (Uyghur), has as its link text, two names separated by a slash and the "dir" was applying to all of it when it should only apply to the Arabic form of the name. This part of the diff (last bit) seems all fine and issue-free; the rendering doesn't seem to have changed before/after — the idea is to simply assign the attribute to the specif bit of text.

stuck a bit above; it has changed the appearance of the ug:wp link-pair; with the dir on the span the link-order is now Latin/Arabic, which is the source-order. Looking at the live page, I see the order reversed. This is due to the text running right-to-left in that link; intentional?

However, I looked at other cases where languages have two forms and noticed an issue. (nb; the others were already doing the "dir" in the span as I changed above)

In two parts of the 1000+ block of ’pedias, we have consecutive links containing "RTL" text which is resulting in odd behavior in all the modern browsers. The two pairs are:

  • “arz:wp, mzn:wp” (Maṣrī, Mäzeruni) and
  • “pa:wp, ps:wp” (Pañjābī, Paʂto)

In these, the "rtl" text is being rendered, well, right-to-left — and this is moving the Latin form of the language name away from the Arabic form and the adjacent link (some other ’pedia) moves into its place. The important thing to see when looking at this, is that the name to the immediate left of the ‘/’ and the name to the right are not to the same ’pedia as is the intent (by folks with minds in a LTR mode, at least). Look at the underline-on-hover behavior and note the discontiguous nature of it.

I'm not sure we can do much about this. I've tried removing the RTL attributes, but the browsers seem to infer it from the characters anyway and nothing much changes. Comments welcome. Cheers, Jack Merridew 08:22, 5 June 2009 (UTC)

more: I've been experimenting. The issue can be made to go away for the current state of the wikis by swapping the order of the spans on either side of the "/". This may be inappropriate given the primary for of the language name in use. We would need input from people familiar with the languages here. Second, this is just a dodge of the issue — which will recur as languages move about and as more RTL languages appear. Cheers, Jack Merridew 11:53, 5 June 2009 (UTC)

I think the best visual solution with Latin+RTL doublets would be to have the Latin version displayed on the left, and the RTL alphabet version on the right, separated with a Latin rightwards slash ("/"). This way, the Latin reader sees "their" string as the first in "their" reading direction, and the Arabic reader sees the Arabic string first in their reading direction. To achieve this, I find I actually don't need any "dir=rtl" at all, quite to the contrary, I need "dir=ltr", which means that only each of the Arabic strings get separately displayed rtl, and all the other stuff around it in the normal way. For me the following seems to work:
Maori • مصرى • Mäzeruni/مازِرونی • Mongol
=code: Maori • مصرى • <span dir="ltr">Mäzeruni/مازِرونی</span> • Mongol
If you want the opposite direction, you'd have to say:
Maori • مصرى • مازِرونی/Mäzeruni • Mongol
=code: Maori • مصرى • <span dir="ltr">مازِرونی/Mäzeruni</span> • Mongol
Works for you? Fut.Perf. ☼ 13:07, 5 June 2009 (UTC)
I saw this last night just before shutting down. I've thought about it and experimented with it. I've just posted what I see as the core of what you're doing, which is to force the dir to left-to-right. I've kept the spans on the individual bit on either side of the ‘/’ which serve to lang-tag the text. This change works in my browsers but I'm not sure if this will be the case all. The core question is whether we want to be specifying the text direction for every bit of text in a RTL language (the page has an ambient dir="ltr” in the html-element) to be semantically correct; this tweak amounts to accepting the notion that the page design is a left-to-right one with other bits of rtl in there. There may be issues with this and I think we need input. If we go this route I would expect to do it for all the bit of rtl text on a “just-in-case” rational. I'll go ping a few folks. Cheers, Jack Merridew 05:48, 6 June 2009 (UTC)
also; I've experimented with flipping the Latin/Arabic vs Arabic/Latin order and it seems to work either way; did this with/ug:wp, too. Sorry for focusing on those two lang families; they're the most common here: pa-Guru is not Latin and Hebrew is not Arabic and the issues apply to them, too, of course. Cheers, Jack Merridew 06:01, 6 June 2009 (UTC)
Well, the core of the problem is, we have a bit of text with equal amounts of rtl and ltr text in it, but we want it to behave as overall within the context of an ltr page. If you have the Arabic form for مصرى first in the source text and the Arabic form for مازِرونی right behind it, but you still want the first to appear to the left of the second, there's no way around marking the ltr explicitly somewhere in their neighbourhood. Fut.Perf. ☼ 06:51, 6 June 2009 (UTC)
I agree; I don't think the layout is going to work with some sort of move in this direction. I am, however, concerned that there may be issues I'm not seeing. I need to go read-up on the recommendations re the dir and direction attributes. Cheers, Jack Merridew 08:08, 6 June 2009 (UTC)

Hi all, I think we can add unicode-bidi: embed; to a selector, this seems to fix the problem (at least at my machine). I tested this solution with IE 7-8, FF3, Google Chrome and it worked very good. Supposing this solution is ok with you, and since the portal depends on MediaWiki monobook CSS (main.css), this means we need to add this property thru another selector (locally, somehow) to avoid any confusions this may cause if it was added in main.css.--AhmadSherif 11:32, 8 June 2009 (UTC)

On a second thought, this may not be a problem, since the page is raw HTML. I was thinking as if the page was a wiki page, but it's not :). So, we can add the new property (and the selector) in any <script> tag.--AhmadSherif 06:28, 9 June 2009 (UTC)
I've been fiddling with this and it seems to me to be automatically in place. Note this edit where I changed the dir attributes from rtl to ltr on text that is inherently rtl. On Firefox, this invokes the second of the following rules from html.css:
/* bidi */

[dir="rtl"] {
  direction: rtl;
  unicode-bidi: embed;
}
[dir="ltr"] {
  direction: ltr;
  unicode-bidi: embed;
}
Other browsers should do something like this. I tried adding a rule
body
{
 unicode-bidi: embed;
}
to this page while removing the dir attributes for the spans mentioned above and it went back to the prior, awkward behavior. I didn't save the edit to the wiki; I do have it off-line.
The relevant bit of the css 2.1 spec is at:
I'm gonna go read it again ;)
My prime concern with this approach is that by basically forcing the issue, we may get undesirable rendering; for example, Arabic characters rendered in reverse order (it is unclear to me whether the first character is on the left or right end of a sequence when I look at it with my setup; I'm also having to zoom-in a lot to be able to see the script clearly).
Cheers, Jack Merridew 07:13, 9 June 2009 (UTC)
I will be straight on this, the way I see for solving this problem is, simply, just adding unicode-bidi: embed; to a selector, to the current version of the portal, resulting something like this revision. Perhaps you could test it and tell me if it doesn't work, so we can figure something out. Regards :)--AhmadSherif 10:07, 9 June 2009 (UTC)
Thanks, I tried this and it works for me. I've merged it in with what I last had done, cutting the dir="lrt” that I had added a few days ago, and posted it. I see that you had indicated the a-element by wrapping it in <code> but had not realized it until just now. The rendering difference was subtle on my machine. I don't quite get why this works, but will look at it further. Thanks much! Cheers, Jack Merridew 14:06, 9 June 2009 (UTC)
There is one minor issue, still (and it may be my LTR mindset). The source order of the pa:wp and ps:wp links is just that; pa, ps per alpha-sort on the language codes, I expect. The pa:wp has two names in pa-Guru/pa-Arab with the slash between them, and the ps:wp follows and is a RTL script (Paʂto). With this new selector in place, it seems that this region of two links and three spans of text is all going right-to-left; note that ps:wp is now to the left of the pa:wp pair. I don't see this as a big problem and it may not be one at all. My primary concern was with the doublet being split and the ps-link appearing in between them. I expect that as more RTL languages get individual wikis more of this will occur and it will either all seem normal or we'll somehow take this whole issue into account in a design iteration. Cheers, Jack Merridew 14:38, 9 June 2009 (UTC)
This leads us to ugly hacks, if we want to keep the right order, we need replace unicode-bidi: embed; with display: inline-block;, and we still in the a-element. Tested too, but there is two things, first, I didn't tested with IE 8, 'cause the browser went crazy somehow, perhaps you can help me in this. Second, but applying this rule may have a slight change on the appearance of the links that may differ from screen resolution to another, also we need check it out, it was fine by me anyway. Regards :)--AhmadSherif 20:11, 9 June 2009 (UTC)
IE 8 works fine now and it works fine too :).--AhmadSherif 20:17, 9 June 2009 (UTC)
I just tried this and had limited success; it works in Firefox (v3.0.10) and Safari (v4.0) but not in Camino (v1.6.7) or SeaMonkey (v1.1.16). The latter two are, I expect, using a slightly older release of Gecko. In the latter two, the links remain in (LTR) ps, pa order; they're also failing to render the pa-Guru script even though I have the font and the other browsers render it. Opera (v9.64) gets it mostly right, but the pa:wp links don't get the proper underline on-hover using display: inline-block; (the "/" and nbsps do get the underline).
I agree that this is getting too messy and am inclined to accept that some regions will go RTL.
Cheers, Jack Merridew 06:37, 10 June 2009 (UTC)
Duh; I put it on the a-element, as you said. This fixed the minor issue with Opera; it does the underline this way. But Camino and SeaMonkey still get it wrong as described above. This is likely to mean that older versions of Firefox and any of the others using an old version of Gecko will have issues.
Please post what you've been experimenting with; I'll pull it out of history and give it a test. When I find myself on other platforms/browsers, I pull my old versions from history and test them further.
Cheers, Jack Merridew 07:02, 10 June 2009 (UTC)
I've been testing with FF3, Chrome 2.0.172.30, IE7 all on Windows XP except FF3 was on Ubuntu--AhmadSherif 10:14, 10 June 2009 (UTC)

simplifying the top-10 markup

See this;

I cut the 10 divs for the individual items in the top-10 wikis that “orbit” the logo and adjusted the css that does the positioning to use the a-element instead. This works just fine for me but I have reverted it as there may be issues with the usual suspects. I'll try and get a chance to test using teh challenged agents. Cheers, Jack Merridew 07:09, 8 June 2009 (UTC)

WebPageTest

Test results of *.wikipedia.org

  • Latency is the most significant factor at higher connection speeds. We should embed instead of linking what is needed. For example we could do without the Monobook.css loaded English Wikipedia and just hard code the styles needed.
  • The tool says that the page from www.wikipedia.org is not compressed. I not sure if this is done on purpose to allow progressive render.
  • According to the tool the specially compressed images can be compressed even future.

Dispenser 08:05, 29 June 2009 (UTC)

I'll look further at these. I agree that we should be cutting unused style sheets. main.css is large and we use little of it.
also:
shows a wide hscroll bar in IE7. This is due to it being, ah, challenged in regard to the 1100% tricks going on with the book images; the bar is allowing slewing over the right 500% that should be hidden. mebbe an inner overflow: hidden; will help; it doesn't seem to hurt other browsers.
Cheers, Jack Merridew 09:41, 29 June 2009 (UTC)

tt:wp note

While I have the windows open ;)

We're currently linking to the "Täwge Bit" page but the top-level redirect goes to the "Башбит" page, as do the internal links on the site. Seems we're linking to an old main page and that they set up a new one and for some reason did not redirect the old one; if the omission was deliberate, fine; possibly they should redirect it. I'm going to go ahead and use the short-form and let the redirect take things to the "Башбит" page.

also

Cheers, Jack Merridew 09:23, 29 June 2009 (UTC)

structure tweaks

I've made a few tweaks. I've cut the <div id="column-content"> level; this is really for the usual wiki pages and it pulls in a rule from main.css that bothers me; 

#column-content {
 width: 100%;
 float: right;
 margin: 0 0 .6em -12.2em;
 padding: 0;
}

I don't see any of it as helpful or needed and the margin-left of -12.2em is definitely not part of this page's look.

I have also cut the class="plainlinks” as not needed; that is for MediaWiki generated links w/class="external” which doesn't apply here.

Finally, I've added overflow: hidden; to the inner bookshelf divs (already on the outer ones). This may help with the hscroll bar shown here in IE7; doesn't hurt. We should be moving on to a post-bookshelf look.

Cheers, Jack Merridew 10:21, 29 June 2009 (UTC) who also slipped “Georgia” into the font-family list for the title

Number of articles

Tell me, please, how edit the number of articles on www.wikipedia.org in Russian section. Very often incompatible with Russian Main page. I ll can help you in this question. Thank you. From Wikipedia ---- Pretenderrs =TALK=

If you know HTML, please edit this page. Otherwise, please tell us what exactly is wrong, so we can correct the problem. (Please note that the front page only reports numbers by the thousands.) Thanks. – Minh Nguyễn (talk, contribs) 03:07, 8 July 2009 (UTC)
Yes, that is only a draft page. Periodically, an administrator here will update the main portal based on the draft. – Minh Nguyễn (talk, contribs) 17:06, 9 July 2009 (UTC)
  • I will can do it every day (yesterday and today 411 000 articles) on wikipedia.org still 410 000. Not interesting :) ---- Pretenderrs =TALK=
Okay. I probably won't be able to update the portal for you every day, but maybe someone else around here can. I usually come here when there's a major change (for example, a wiki reaches a milestone or someone improves the HTML code). – Minh Nguyễn (talk, contribs) 21:07, 10 July 2009 (UTC)
  • I agree with you. I'll update the draft page, and someone will update portal. OK? ---- Pretenderrs =TALK=

Per sents on edit page

How necessary edit per sents on edit page with accord number of articles? I'll can calculate it. ---- Pretenderrs =TALK=08:35, 18 July 2009 (UTC)

Scheme-less URLs

I do not know where this is standardized (if it is) but it works in all the major browsers. We can eliminate the scheme identifier from URL, saving 5 bytes on each link. Example <a href="//en.wikipedia.org/"> Dispenser 13:23, 27 July 2009 (UTC)

It is standard, and I've heard of it being used on sites that operate both on HTTP and HTTPS, so that images and stylesheets can be loaded via the right protocol without triggering a certificate mismatch warning. But even though it's standard, it's a very little-known trick, so I don't know whether it'll work in every browser, either. Then again, we could also shave off many more bytes by switching back to HTML 4 and omitting xml:lang and quote marks where the attribute value is alphanumeric (many langs). Do you think omitting the scheme would be too desperate? – Minh Nguyễn (talk, contribs) 06:57, 13 August 2009 (UTC)
So a few other users decided to be bold and converted the portal to HTML5. That did shave off quite a few bytes. – Minh Nguyễn (talk, contribs) 08:56, 19 September 2009 (UTC)
I tried it and we save about 1.5 KB off the raw HTML (~45 KB). RFC 1808 gives scheme-less URL as an example so I think we're good to implement this. I've make a few other changes in regards to content moving around and bits.wikimedia.org. The only thing I haven't tested any JS like the zh changer thing, but I think the code we have should work. Dispenser 18:08, 30 April 2010 (UTC)
Because we now need this for HTTPS to work, I am making URLs protocol-relative on all of these www template pages. This means that the data URI preview hack no longer shows images, though. --Catrope 11:22, 1 October 2011 (UTC)

Page visits

Don't know if this is the best place to ask, but is there any where I can get the number of hits/visits for www.wikipedia.org? It's easy to find sites for the different languages but I can't work out where to get official stats for www.wikipedia.org Nil Einne 17:16, 18 September 2009 (UTC)

Good question. The best person to ask would probably be Erik Zachte, who maintains the Wikistats website. – Minh Nguyễn (talk, contribs) 08:55, 19 September 2009 (UTC)

My opinion

The page there have to get a <includeonly> tag, because it shows very bad (and strange). --MisterWiki 23:16, 7 October 2009 (UTC)

It's supposed to look bad. :-) The exact text on that page shows up on http://www.wikipedia.org/. Cbrown1023 talk 22:45, 8 October 2009 (UTC)

Two errors (Arabic)

Hi. I'm a native speaker of Arabic. There are two errors on the main page. First, when I point at the Arabic word for "search", the tooltip says "Bahs", which is wrong. The standard pronunciation of the word "بحث" is "Baḥth", where "-th" is pronounced as in the English word "three" (see the "بحث" entry on the English Wiktionary).

The other error is when I point at the word "العربية" (the Arabic Wikipedia link), the tooltip says "Araby", but the actual word that's written there is "Al-ʿArabiyah" (see the "Arabic language" article on the English Wikipedia). Thank you. --84.255.184.205 21:18, 2 December 2009 (UTC)

The errors have been corrected. Thanks for your help. – Minh Nguyễn (talk, contribs) 01:44, 7 December 2009 (UTC)
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:Www.wikipedia.org_template/2009&oldid=22165770"