Talk:Releases/Acai

Problem reverting preferences

Hello, I put this one as a user preference and I don't like it at all. I wanna turn back but when I click into My preferences it's empty. What can I do please?

Sorry to hear that you have trouble getting out of the new skin. Not sure why your preferences show empty. Would you let us know the version of the browser and OS? If you can get into preferences, just go to "Appearance" and chose monobook (default) and disable the enhanced toolbar from "Editing" in your preferences. --Shuhari 00:10, 3 July 2009 (UTC)

Unfortunaletly I can't do this, as the preferences is still empty just to go to appearance or anywhere else. I must add that all this happens to greek Wikipedia. I use IE7.

I can't reproduce your problem on el.wikipeda.org using IE7. Will you try clearing the cache and restart the browser? Are your friends using IE7 experiencing the same problem? --75.101.56.5 00:58, 3 July 2009 (UTC)

I've already done this (clearing the cache and restart the browser), as I have this problem about 24 hours. I don't know if anybody else has the same problem.

I finally download IE8 and succeeded to get rid of this skin. Thank you very much for the interest. 94.68.19.147 02:52, 3 July 2009 (UTC)

Glad to hear the you could restore your preferences. We will keep an eye on the problems similar to what you had experienced. --Shuhari 04:56, 6 July 2009 (UTC)

---

I guess I miss something. I do have the option for the Vector interface in Appearance tab of user preferences, and choosing that I can see most of the improvements. But I could not locate an option for the improved toolbar in the Editing tab or anywhere else, and (now it's live) I did not find an Opt-in/Opt-out page either. What do I miss? Were these removed from the release? --Geraki 16:05, 10 July 2009 (UTC)

Opt-in/out feature will be enabled once Right-to-Left language support is available. We will keep you all posted. Naoko Komura --Shuhari 19:52, 17 July 2009 (UTC)

Signatures

Are there plans to put signatures in the toolbar for the Wikipedia namespace? It's really annoying having to sign manually for WP-space discussions.--Ragesoss 18:41, 17 July 2009 (UTC)

We received the same feedback quite often, so we will be making the signature icon available for all pages except article pages. The change should be deployed with in a week or so. Naoko Komura --Shuhari 19:50, 17 July 2009 (UTC)

Awesome! I see that it's live now. And the new signature icon with the stylus is a big improvement.--Ragesoss 15:36, 18 July 2009 (UTC)

Math

Hi!

Why the <math></math> button was removed? Shouldn't it be at the "advanced" section of the toolbar? Helder 13:07, 21 July 2009 (UTC)

I think <math></math> button is very important, too. Give it back! --gerson 00:48, 7 August 2009 (UTC)

Bold and italic buttons

The new buttons for making text bold, italic, and changing font size look pretty, but they are nowhere near as recognizable and usable as the existing buttons. The fact that they are 3D, stylized in different fonts, and drop-shadowed makes it very difficult to tell what the icons' functions are at first glance. Also, I know that you guys want to get away from using "B" and "I" as they are english-centric, but please consider that those letters are used as icons for "bold" and "italic" in countless programs, WYSIWYG editors, and other environments across the world, regardless of language. I imagine most web-literate people across the world recognize their meaning even if they don't know the words they stand for. If usability is our top priority, we shouldn't be abandoning recognizability for eye-candy. Kaldari 18:11, 21 July 2009 (UTC)

I second this. It is hard to tell which is bold and which is italic. --207.133.179.19 18:39, 23 July 2009 (UTC)

Maybe a small change in the colors used would be sufficient (e.g. making the a more light and the a more dark). Helder 11:48, 29 July 2009 (UTC)

The fact that one button uses a single-story a and the other uses a double-story a is also confusing. It definitely gives me the impression at first glance that those buttons have something to do with setting fonts rather than styles. 166.77.6.4 18:16, 29 July 2009 (UTC)

I think you should have text below them. Werdna 16:33, 4 August 2009 (UTC)

Probably it'd be sufficient to make the lines finer for the non-bold buttons to emphasize the difference between bold and non-bold. I'm not sure what to do for italics if there are still issues where. Mike.lifeguard 15:56, 6 August 2009 (UTC)

I agree totally with Kaldari: "B" and "I" are really better! --Aushulz 00:49, 7 August 2009 (UTC)

Agreed. Not only are the B and I internationally recognizable, but most computer-using Americans know them from Microsoft Word so the value goes way up. --Jeff Grimes 18:33, 14 August 2009 (UTC)

Please reconsider the editor buttons before going live. The use of B and I are much more intuitive, and is the de-facto standard. Having every button labelled a looks like some uncyclopedia article. - hahnchen 00:29, 16 August 2009 (UTC)

WYSIWYG

I really like the new skin and toolbar, and have glanced through both Acai Designs and Babaco Designs; it looks very promising indeed. However, I was hoping for full WYSIWYG editing, something along the lines of WordPress' in-browser editor. Where the editing window displays the output of complex templates as one adds content to it. As well as the option to switch between WYSIWYG and code editing modes. Just two cents from a Wiki-markup-impaired editor. :) BlazerKnight 02:36, 30 July 2009 (UTC)

The usability has already evaluated several editors. Many users denounce here (include me) of adding anything more than color highlighting. Anyway, there has not be a system to date that deals with templates effectively. Dispenser 13:51, 30 July 2009 (UTC)

And many other users, including participants in the usability initiative, roundly desire WYSIWYG editor. I'm amazed that one of the "supported" (by yourself, Dispenser) parts would be "color highlightingoogle", only because in my opinion that's one of (along with text size selector) the most frequently abused, mis-used, and typographically nonsensical things which naive people do with WYSIWYG editors. The solution to that is NOT to make naive users learn wikicode, but to keep color and size tools OFF the WYSIWYG toolbar - it's possible to only provide the tools which are relevant in a particular content repository. Wikimedia doesn't even have color highlighting now - in fact, wikicode itself doesn't have syntax for text color, as far as I know. Leaving aside the question of adding a new wiki textformatting feature, why in the world would you support WYSIWYG for color but not for any other format? How would you even implement that? You'd need 2 views - one for wikicode and one for WYSIWYG and "live preview". To go to the effort to develop that and NOT provide the rest of the format tools would be criminal. Last point: newbies aren't the only ones who would find WYSIWYG useful. I'm fluent in wikicode but it's still hard to read "bare". WYSIWYG or "live preview" would really help make lengthy edits, reading coded text looking for errors or one-word vandalisms, and similar tasks more efficient and enjoyable. This idea that "it's supposed to be hard, you're not supposed to enjoy it" is contrary to the values of Wiki culture. It reinforces perceptions of elitism on the part of the cabal, and it assumes bad faith on the part of newcomers. 71.198.34.87 12:40, 11 October 2009 (UTC)

I was speaking of syntax highlighting, I support a WYSIWYM editor. I disagree with hiding human understandable markup as much as I disagree with Microsoft hiding of keyboard shortcuts and menu items. Dispenser 04:41, 21 October 2009 (UTC)

Table of contents

It goes against usability to remove indentation on table of contents, making much more difficult to separate top sections from subsections: [1] Drini 15:53, 30 July 2009 (UTC)

Indentation is planned to be added to the advanced mode in the next release. --Shuhari 02:12, 1 August 2009 (UTC)

I think what you were talking about was actually a bug that's been fixed and will be pushed out to the projects on August 5th. --Trevor Parscal 16:35, 4 August 2009 (UTC)

Search Anyone?

I absolutely love the look... the only thing that is majorly missing is the awesome Auto-Complete Wikipedia search bar on the left nav... Add that and I think I'll keep the theme.

Search is in the top right corner :-) --Eloquence 21:21, 30 July 2009 (UTC)

Enhancements to the search in the top right are coming in future releases, and can be seen at http://prototype.wikimedia.org/sandbox --Trevor Parscal 16:36, 4 August 2009 (UTC)

The search in the top right is much harder to spot than it should be given that it is a main means of navigation, particularly when all the buttons have been trimmed off it. I'd prefer to see it under the logo at the left. 131.111.220.6 23:58, 5 August 2009 (UTC)

I absolutely agrre to the opnion above! For me search field is the most common used item on the left navigation column. Combined with the new blurry look it is challenging to spot it in the top right corner far away from the main navigation.

Search should be on the left, it's intuitive for all right-sided writings (latin, south asia,...) and vertical writings (Asia,...), who are right-sided too (read the top of the row on the right after reading the bottom of the collumn on the left). Search should be on the right side for the left-sided writings (arabic,...) and some vertical writings which are left-sided (japanese,...), look at the arabic wikipédia, toolbar is at the right. But, why should it be on the upper right ? any rationnal reason? JackAttack88.164.186.229 22:25, 28 August 2009 (UTC)

"the new blurry look" ;-) Dispenser 04:44, 21 October 2009 (UTC)

I can't agree. I like the search bar in the rigth upper corner. It has more space there. Displays are growing wider nowadays. Think about notebooks, it's almost impossible to get a good old 4:3 or 5:4 diplay, they are all 16:10 or even 16:9. there is already enough space wasted by all the main menu entries which requires all the space of the left bar. I already have to scroll down with a display with more than 1000 pixels of hight only because there are so many entries in the left side menu. --91.8.135.154 19:31, 11 October 2009 (UTC)

Find and Replace?

A Find and Replace button would be very useful, like the one that ThomasV made for the French Wikisource : in our toolbar it looks like this. It takes words and it takes regular expressions too if we wish to use them. Would it be possible? --Zyephyrus 18:12, 31 July 2009 (UTC)

This sounds like it would be extremely useful if it could be done. --Tktktk 18:35, 7 August 2009 (UTC)

It WAS done. By ThomasV. At French Wikisource. 71.198.34.87 12:48, 11 October 2009 (UTC)

Left column

Personally, I need the section in left column (Navigation, Toolbox etc.) more distinguiehed from each other... now it looks like a whole one long column of links and I barely see the section headings...--Kozuch 12:01, 1 August 2009 (UTC)

PDF option missing

Hi,

I miss the PDF generation option present in the monobook skin.

--Lunchboxhero 17:41, 1 August 2009 (UTC)

This sounds like a bug. I filed a bug 20067 --Shuhari 17:55, 4 August 2009 (UTC)

Speak to the blind?

Some real strides are being made in accessibility, congratulations!

We lack the ability to read our articles out loud to the blind, which is related both to accessibility and the "education instead of simply assimilation of knowledge" criterion which the UK chapter is facing in its attempt to obtain charitable status.[2]

Both non-commercial (e.g. [3], [4]) and commercial ([5], [6]) solutions can address this problem. I believe a site license for a commercial product is easily within the reach of the Foundation.

Please consider this enhancement. Thank you. 99.22.93.63 18:54, 1 August 2009 (UTC)

The Wikimedia Foundation uses only free/libre open source software (FLOSS) to run the wikis. I suspect the goal here will be to ensure screen readers like JAWS work as expected. If you have suggestions that use FLOSS, or suggestions to make sure screen readers work, they'd certainly be welcome! Mike.lifeguard 16:00, 6 August 2009 (UTC)

The first two links, for Festival and Festvox, meet your criterion, but sadly they are of lesser quality than the other two. Many of us believe that it is worth spending a little money to accomodate those with disabilities. Do you really think that the multitudes of blind should have to pay for their own individual screen readers when a site license to the best speech synthesis system that money can buy, which could proxy all Foundation content, is easily within reach? 76.254.66.195 16:23, 7 August 2009 (UTC)

Most people with vision impairment have their own accessibility tools already - whether they use open source or proprietary software makes no difference to us. The Wikimedia Foundation uses FLOSS not because it is free (as in "free beer") but because it is free (as in "freedom"). Mike.lifeguard 20:54, 7 August 2009 (UTC)

Do you mean to say, "most people with vision imparement in the first world"? Providing a high-quality reading service to those who are not able to afford their own, even if it is something that the Foundation has to pay a site license for, is very much aligned with the goals of freedom, is it not? 99.60.0.185 17:57, 9 August 2009 (UTC)

No, we use FLOSS & that will always be a core part of our mission. Please suggest courses of action in line with our mission. Mike.lifeguard 19:27, 23 September 2009 (UTC)

Two have been suggested. Do you mean to say that it was not appropriate to mention commercial software? In some cases, the commercial business model may be more appropriate. Software is too complex for such blanket statements. 99.34.79.144 20:07, 12 November 2009 (UTC)

One button to switch between several toolbars

Would it be possible to switch easily from your toolbar to the longer French Wikisource toolbar (more than 30 buttons) and back to your toolbar near the same button of WikiEd (or even perhaps one button for switching between the three of them : your toolbar, the WikiEd toolbar(s), the 30 buttons wikisource toolbar?) --Zyephyrus 23:40, 1 August 2009 (UTC)

Wasted space

There appears to be about one line of empty whit space at the top, moving the actual article text further down than Monobook. This makes it much less convenient to read on a small screen. There is also too much interface stuff at the bottom, below the article. Otherwise, I like the new look. --Apoc2400 10:23, 3 August 2009 (UTC)

I very much agree, and it's a problem that affects every article you read. If it's at all possible to reduce the amount of space at the top, please do so. --Tktktk 18:35, 7 August 2009 (UTC)

I do disagree, it provides a clearer and more attractive design IMO. 89.217.199.175 20:16, 7 August 2009 (UTC)

Forcibly taking real estate is never a good idea. screen space is always a premium. Please lose the spare line --63.116.23.136 04:37, 13 August 2009 (UTC)

Headings in Açai toolbar

I think they need to be moved out of a hidden 'advanced' menu – they're probably going to be used much more than, say, images and links. In quick hand-to-my-girlfriend-to-play-with usability testing, she couldn't figure out how to add a heading, even with the advanced menu open.

Generally speaking, people use drop-down lists for input, not for 'committing' an action. Werdna 16:36, 4 August 2009 (UTC)

I agree. In general, there is room for a few more buttons instead of just "Advanced" and "Special characters" and "Help" on the toolbar. I think that headings would be perfect to have its own section. --Jeff Grimes 18:27, 14 August 2009 (UTC)

Expanding div

Hi, i tried Vector skin but there's a problem with hiding div. For example here: "expand link" is missing. I think it's included in "NavFrame" style. --Quaro75 21:07, 4 August 2009 (UTC)

Editing toolbar improvements

Referencing this editing screen

Overall I like the new editing interface. However the editing toolbar and advanced editing toolbar themselves are capable of great improvement. The actual icons are not good choices ("italic" is in a heavy font so the "bold" icon looks like "normal" weight, "a+" is explained textually but not visually intuitive, "baseline" is a technical term). Also, the choice of which icons to display is an issue. Last, several icons just insert wiki markup, leaving the user the same job of working it out from there.

I would propose a simpler and more effective main toolbar, like this:

These are the main icons a user needs. The icons are simpler, and improved. For example the icon for a reference shows an actual citation, which is how most users see cites, rather than a book which could mean anything (scan the text in? add a quotation from a book?). The icon for signature is at 45°, to imply the pen is moving. There is one icon for links not two (the popup allows users to enter both kinds, and clues such as "http://", common TLDs, or spaces in the name will guide interpretation in the vast majority of cases).

I would then ensure that the options requiring parameters, such as tables links and references, have a popup, drop down, or other box, in which the user can enter the most common options, so they don't need to edit the markup:

Finally, the following icons might be useful, but not often or to most users - most users don't need to vary text heights, and most articles and discussions (sciences and math aside) don't have great use of super and subscript. Have these as an optional "show more formatting options on the toolbar" (not "advanced"), but don't show them by default:

FT2 01:51, 5 August 2009 (UTC)

FT2, I like very much this toolbar: I see it so simple, so understandable, so harmonious. --Zyephyrus 10:48, 7 August 2009 (UTC)

I'm not too impressed with the icons, but you have the right idea. Popups can be really useful; refTools would work well in that capacity. HereToHelp 11:49, 11 August 2009 (UTC)

Some powerfull improvements proposed. Please, make a merge with the former tool bar ! 78.231.120.5 14:20, 12 August 2009 (UTC)

I like the idea for an expanded references table, which would make references painless for new editors. But the overarching toolbar should probably still have the one-click reference button, in addition to a drop-down menu (for quick references). This way newer editors can gain exposure to the actual markup language, and complement that exposure with the pre-baked reference table you are suggesting. Great idea. -Jeff Grimes 18:19, 14 August 2009 (UTC)

Some SVG versions for baseline (22px)

• 
• 
• 
• 
• File:Format-ulist.svg
• File:Format-ulist.svg
• File:Format-big.svg
• File:Format-small.svg

References and cites

(Added back from this edit, not sure why removed)

On reflection, I'd do references like this:

Give the user a dropdown box for the reference type. Not all projects have the same types, but this can easily be managed via a local "Mediawiki:" page containing the local data (see below). The end result to the user for clicking the "reference" icon on en-wikipedia would be a popup like this:

The center portion adapts according to the selection in the top box.

The config for this is in a Mediawiki: page on the local project, of the form:

Citation from a news source
   template = cite news
   url = URL (web link)
   title = Title
   pubdate = Publication date
   pubname = Publisher's name
   (names of other parameters for this type of entry...)
   Note_text: News sources used should be (whatever)
Citation from a book
   template = cite book
   title = Book name
   pubname = Publisher
   pubdate = Date published
   firstname = Author first name
   lastname = Author last name
   (other parameters)
   Note_text: Books must be reputably published, see [[Wikipedia:Reliable sources]].
....
   ....
Any other citation or reference note:
   Note_text: Please enter the text for the note below.

The unindented items are the "standard types of reference" for this project, shown in the "type" dropdown box. When a user selects a "type", if it has a "template" with one or more parameters (format: param_name = user_prompt), these will be presented to the user for entry as well, and any note will be presented as guidance. A freeform "additional text" box is always available. Optionally it would be trivial to mark mandatory fields with a * or allow a default (eg for date checked).

In each case, the resulting reference contains the named template (if any) with their named parameters, followed by the freeform text (if any). The prompts should allow markup so they can link to explanatory text in a popup or new window, or else a "help" icon linking to such a page.

Instant references, customized with the common kinds of references defined project-by-project, easily updated, and neatly formatted.

FT2 02:49, 5 August 2009 (UTC)

Very cool mock-up. Without boiling the ocean, I think we want to consider whether we can come up with an approach that works for other complex templates as well, rather than creating a citation-specific solution.--Eloquence 20:35, 6 August 2009 (UTC)

Citation is very common, so it could use special attention. refTools is a gadget that does something similar. --Apoc2400 00:08, 7 August 2009 (UTC)

Please remember we run more than just (English) Wikipedia. Yes, the usability initiative is specific to Wikipedia, but let's not go out our way to work on things that will explicitly benefit only one or two out of several hundred of the wikis we run. Mike.lifeguard 20:51, 7 August 2009 (UTC)

Upper case and lower case

I hate upper case and lower case characters mixed together (in "Special characters"). --Aushulz 00:56, 7 August 2009 (UTC)

You bring up a good point - it would be nice if special characters could not only be sorted by language but also by frequency and upper case vs. lower case. --Jeff Grimes 18:35, 14 August 2009 (UTC)

Less charachters and not "copy&paste-bles"

I saw that there are a very little characters in "Special characters", and I can't paste and copy it together, cause appears:

---

ÁáÀàÂâÄäÃãǍǎĀāĂ㥹ÅåĆćĈĉÇçČčĊċĐđĎďḌḍÉéÈèÊêËëẼẽĚěĒēĔĕĖėĘęĜĝĢģĞğĠġĤĥḤḥĦħÍíÌìÎîÏïĨĩǏǐĪīĬĭİıĮįĴĵĶķĹĺĻļĽľḶḷḸḹŁłĿŀṂṃŃńÑñŅņŇňṆṇÓóÒòÔôÖöÕõǑǒŌōŎŏǪǫŐőŔŕŖŗŘřṚṛṜṝŚśŜŝŞşŠšṢṣŢţŤťṬṭÚúÙùÛûÜüŨũŮůǓǔŪūǖǘǚǜŬŭŲųŰűŴŵÝýŶŷŸÿỸỹȲȳŹźŽžŻżÆæǢǣØøŒœßðÞþƏə pt̪tʈckqʡʔbd̪dɖɟɡɢɓɗʄɠʛt͡st͡ʃt͡ɕd͡zd͡ʒd͡ʑɸfθsʃʅʆʂɕçɧxχħʜhβvʍðzʒʓʐʑʝɣʁʕʖʢɦɬɮmm̩ɱɱ̩ɱ̍n̪n̪̍nn̩ɳɳ̩ɲɲ̩ŋŋ̍ŋ̩ɴɴ̩ʙʙ̩rr̩ʀʀ̩ɾɽɿɺl̪l̪̩ll̩ɫɫ̩ɭɭ̩ʎʎ̩ʟʟ̩wɥʋɹɻjɰʘǂǀ!ǁʰʱʷʸʲʳⁿˡʴʵˢˣˠʶˤˁˀʼii̯ĩyy̯ỹɪɪ̯ɪ̃ʏʏ̯ʏ̃ɨɨ̯ɨ̃ʉʉ̯ʉ̃ɯɯ̯ɯ̃uu̯ũʊʊ̯ʊ̃ee̯ẽøø̯ø̃ɘɘ̯ɘ̃ɵɵ̯ɵ̃ɤɤ̯ɤ̃oo̯õɛɛ̯ɛ̃œœ̯œ̃ɜɜ̯ɜ̃əə̯ə̃ɞɞ̯ɞ̃ʌʌ̯ʌ̃ɔɔ̯ɔ̃ææ̯æ̃ɶɶ̯ɶ̃aa̯ãɐɐ̯ɐ̃ɑɑ̯ɑ̃ɒɒ̯ɒ̃ˈˌːˑ˘.‿|‖ ~|¡¿†‡↔↑↓•¶#½⅓⅔¼¾⅛⅜⅝⅞∞‘“’”«»¤₳฿₵¢₡₢$₫₯€₠₣ƒ₴₭₤ℳ₥₦№₧₰£៛₨₪৳₮₩¥♠♣♥♦m²m³ ΑΆαάΒβΓγΔδΕΈεέΖζΗΉηήΘθΙΊιίΚκΛλΜμΝνΞξΟΌοόΠπΡρΣσςΤτΥΎυύΦφΧχΨψΩΏωώ

---

It don't appear in the old interface, where the same action give:

---

Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο Π Ρ Σ Τ Υ Φ Χ Ψ Ω α β γ δ ε ζ η θ ι κ λ μ ν ξ ο π ρ σ ς τ υ φ χ ψ ω ὰ ά ᾶ ᾳ ᾲ ᾴ ᾷ ἀ ἂ ἄ ἆ ἁ ἃ ἅ ἇ ᾀ ᾂ ᾄ ᾆ ᾁ ᾃ ᾅ ᾇ Ἀ Ἂ Ἄ Ἆ Ἁ Ἃ Ἅ Ἇ ὲ έ ἐ ἒ ἔ ἑ ἓ ἕ Ἐ Ἒ Ἔ Ἑ Ἓ Ἕ ὴ ή ῆ ῃ ῂ ῄ ῇ ἠ ἢ ἤ ἦ ἡ ἣ ἥ ἧ ᾐ ᾒ ᾔ ᾖ ᾑ ᾓ ᾕ ᾗ Ἠ Ἢ Ἤ Ἦ Ἡ Ἣ Ἥ Ἧ ὶ ί ῖ ἰ ἲ ἴ ἶ ἱ ἳ ἵ ἷ Ἰ Ἲ Ἴ Ἶ Ἱ Ἳ Ἵ Ἷ ὸ ό ὀ ὂ ὄ ὁ ὃ ὅ Ὀ Ὂ Ὄ Ὁ Ὃ Ὅ ῥ Ῥ ὺ ύ ῦ ὐ ὒ ὔ ὖ ὑ ὓ ὕ ὗ Ὑ Ὓ Ὕ Ὗ ὼ ώ ῶ ῳ ῲ ῴ ῷ ὠ ὢ ὤ ὦ ὡ ὣ ὥ ὧ ᾠ ᾢ ᾤ ᾦ ᾡ ᾣ ᾥ ᾧ Ὠ Ὢ Ὤ Ὦ

---

So I really prefer the old version, Beta are really worse at the moment... --Aushulz 01:04, 7 August 2009 (UTC)

Wikificator

I wonder if meta:Wikificator is supported yet? I know it's not widely used, but editor is almost unusable in Russian Wikipedia without it 93.170.2.97 11:00, 7 August 2009 (UTC)

Some special characters removed

Some of the special characters I used the most are not in among new Special characters. Those I miss the most are –, —, −, ±, × and ·. Of course, I know how to write them using HTML character entities but I find that less convenient. Svick 12:19, 7 August 2009 (UTC)

Other important missing characters are the DMS symbols ° ″ ′, used for coordinates and other types of sphere notations. 82.75.218.92 00:07, 8 August 2009 (UTC)

Loss of textarea contents

Hi there,

First of all, I'd like to just say that I think the new theme is excellent. I've been a graphic designer and web programmer for several years now and I think this is a major step into the right direction for the Wikimedia Project. I've always been skeptical to things that concern Wikipedia's graphic design, mostly because the status quo is already quite good, but this beta has given me the hope that everything is going to work out just fine.

One issue that I'd like to raise, however, concerns the contents of the edit box--they get lost when navigating away. Monobook has a simple <textarea> in the source by default which works quite well because the browser keeps its contents around even when one is no longer on the same page as the element. I haven't checked exactly how it works in the beta, but I suppose it creates the element dynamically using JavaScript, which would break such behavior.

I think it would be problematic, in this case, if someone was writing a long reply, then accidentally clicked one of the links below the editor. It's certainly an improvement that the editor initially prevents you from navigating away (the old one doesn't, forcing the user to either go back later or press the stop button). However, my concern is that modal windows can be scary in addition to being helpful--who hasn't accidentally clicked "no" when asked if they wanted to save their document at some point? When the user does manage to navigate away from the page (which happened to me a while ago when I tried out a JavaScript editor for Wikipedia), the contents of his edit are completely lost.

It doesn't have to be that way, of course. I'm sure there's some way to fix it (maybe we should keep the original textarea around and wait for it to receive contents from the browser). But I'm foremostly interested in whether this is a known bug and if a solution is already in mind. Otherwise I'd be happy to run some tests to see what would work.

Thanks! 195.241.69.171 14:57, 7 August 2009 (UTC)

Bug: I am using Opera 9.64, and I don't get the modal windows to prevent me from getting away. But the text is lost anyway. Is this a known bug ? Dodoïste 20:30, 7 August 2009 (UTC)

I can reproduce this bug, having just lost an important page I worked on, in Firefox 3.5.2.--Eloquence 00:21, 8 August 2009 (UTC)

The usability dev team identified that the cause of this problem is the drop-down widget for the header. The solution will be applied as soon as it is available. Bug 20294 --Shuhari 21:26, 17 August 2009 (UTC)

Feedback from enwiki

Just an FYI on some feedback from enwiki over here. There's some good suggestions buried in the discussion. ^demon 17:49, 7 August 2009 (UTC)

Problems in hindi wikipedia

In hindi wikipedia we have added translit.js to transliterate english (roman) charecters to hindi(devnagari) charecters. Translit.js works in editer window ,search bar and in many more fields but it dosent seem to be working with new Acai beta theme . Kindly help --sumit sinha

It is a local script. You will need to find it's author or maintainer in the history of the script. 82.75.218.92 00:09, 8 August 2009 (UTCA)

Syed Tahir Abbas Bukhari

Toolbar is not visible on Arabic Wikipedia (Internet Explorer only)

It seems that there's a bug that makes the edit toolbar invisible on the Arabic Wikipedia. It works in Firefox and Google Chrome, but not in IE7 and IE8. There's also a huge horizontal bar that is not supposed to be there (when I edit an article). --84.255.141.125 12:56, 8 August 2009 (UTC)

We are looking into what are causing these issues. --Shuhari 16:52, 10 August 2009 (UTC)

Still have not found a solution. The enhanced toolbar for RTL languages will be disabled until the solution is in place. Bug 20293--Shuhari 21:10, 17 August 2009 (UTC)

Forgot to post the updated here...the toolbar is supported in IE8 for right-to-left languages. Please see the compatibility matrix for Acai here.--Shuhari 01:52, 12 October 2009 (UTC)

Random stuff from nl.wiki

Hi,

Overall I like the beta and see it as an improvement. However a few things I noticed:

• On the top of the page (to the right of Page, Discussion - to the left of Read, Edit and Try Beta) there's a lot of dead empty space that not only is caught by the eye (attracts attention) but also pushes the content further down.
• The left sidebar has much valuable content but is out of attention and lacks attention.
• The Personal Links on the top right looks like a stack of links that just eats space

My idea is to:

• move the navigation from vertical left to horizontal top.
• Get rid of the sidebar (maybe make it an option in the settings, or make it expandable (from a 2px line with a button to the current sidebar) - or just get rid of it permanently
• Make a roll-over - dropdown menu on the top right as something like "My Account", it saves space and is more usable i.m.o

This makes more space, and at the same time gives room for more links. So more information in less space at the same time.

My 2c, Krinkle

typing mistake

On [7] at "Was wurde verbessert?"/"Verbesserungen der Werkzeugleiste" theres a wrong vowel in the last sentence. Instead of "Zugriff" the text reads "Zugruff" -- 85.181.27.41 15:40, 10 August 2009 (UTC)

This should be corrected at TranslateWiki. --Catrope 17:43, 10 August 2009 (UTC)

Usability Team's Thoughts on the Header Spacing

We have received a significant amount of feedback on the spacing at the top of the page (the header) - some saying that there is too much empty or "negative" space. In response to your comments, we wanted to share with you the reasoning behind our design and decisions and let you know that we are always open to change or being wrong.

In the Usability Study we conducted in March, we aimed to uncover and discover barriers to editing that new users face with the current editing interface. Surprisingly (and not so surprisingly) we found that in addition to troubles users faced once they made it to an edit page - a large part of the problem was just getting to the edit page or more generally finding what one was looking for. "I'm thinking it's a little confusing, it's a lot of information," "There's a lot to look at right now," and "I'm not sure where to look" are just a few of the statements we hear repeatedly on article, help, and discussion pages. Statements like these were part of our motivation to tackle a skin redesign. In designing and developing Vector, one of our goals was to reduce the burdens of visual attention on users in the hopes that it will make navigating the site (to and on edit pages, watchlists, discussion pages, etc..) easier. Whether or not it accomplishes that, we are not yet sure. We increased that space believe that it made the User tools more distinguishable than the navigation tabs, making access to both of those areas of mouse action more readily identifiable and accessible, Gestalt style. We have an iterative process and part of this is receiving your comments. Another part of this is evaluating our changes. We will be conducting a second Usability and Experience Study in late September and are also looking at the possibilities of statistical evaluation, bucket testing and (if we can make it happen) eye tracking.

Just as we wouldn't want to implement a design without sufficient reason, we do not want to revert one without first evaluating it. Your comments have given us greater reason to look at this in our continuing evaluation. If it does not serve our goals, we will be changing it and re-evaluating until we find something that does! We are committed to improving the editing experience for new users and community members. Pleasing everyone on every aspect is an impossibility, but we are putting forth our best effort to make an overall improvement for everyone that comes and can contribute to Wikipedia. --Parul Vora 21:32, 11 August 2009 (UTC)

I love the new layout of the header, except for the arrow next to "View History". It seems a bit awkward to have an arrow with just two options on it (watch and move). I think it would look better and more continuous if Watch and Move were just placed as regular blue buttons alongside the other four in the top right. --Jeff Grimes 18:31, 14 August 2009 (UTC)

Problems with user pages

Just look.91.77.221.236 08:40, 12 August 2009 (UTC)

Will you let us know the resolution of your screen and OS of your computer? Bugsubmitted. --Shuhari 21:57, 13 August 2009 (UTC)

1280x1024, Linux (Ubuntu 9.04), Firefox 3.0.13. Well, indeed I have minimal fontsize set in firefox to 18 --- otherwise fonts in wikipedia are too small for comfortable reading. 91.76.179.21 13:19, 14 August 2009 (UTC)

Problem with baseline icons

In the advanced box, the baseline icons are not great. I encourage you to use more intuitive icons, with the key par enlight in blue, like in the Silk icon set.

silk icon (16px)

• 
  format-superscript.png
• 
  format-subscript.png
• 
  format-ulist.png
• 
  format-ulist.png

---

My SVG proposal (22px)

• 
• 
• 
• 
• File:Format-ulist.svg
• File:Format-ulist.svg
• File:Format-big.svg
• File:Format-small.svg

Size: 22px.

Yug (talk on commons) 14:14, 12 August 2009 (UTC)

Same for the lists. The dots, and the numbers should be enlighten with blue. Yug (talk on commons) 14:14, 12 August 2009 (UTC)

I just noticed, and support FT2 proposal seen upper : Talk:Releases/Acai#Editing toolbar improvements. Yug (talk on commons) 14:17, 12 August 2009 (UTC)

text shrunk since yesterday on 120dpi monitor

I like most of the features of "Try Beta", but the text size of body text has shrunk since yesterday so I've stopped using the Beta as the font size is now too small for my aging eyes. I'm guessing this is connected to my settings − my laptop screen has 120dpi (1440x900pixels, 14.4 inches diagonal). I'm using IE7 under Windows XP, with Display Properties -> Settings -> Advanced -> DPI Settings set to "Large Size (120 DPI)". I've not changed any settings since yesterday, other websites look the same as usual as does the monobook skin, so it seems to me that it must be the result of a change your end. Apologies if I should be reporting this using the bug tracking tool, but that's beyond me. Regards, Qwfp 15:35, 12 August 2009 (UTC)

Toolbar

You seem to have removed the only toolbar button I ever used: #REDIRECT. Stevage 06:59, 13 August 2009 (UTC)

Missing "featured article" icon on dewiki

The "featured article" icon on dewiki is missing in all articles (should be in the upper right corner). Tested with Internet Explorer and Firefox --84.61.243.217 07:11, 13 August 2009 (UTC)

I made a fast bugfix at Bulgarian Wikipedia. Most probably this breaks something else. — Borislav 12:32, 25 August 2009 (UTC)

Special characters times two

I find it a bit messy to have both the new "Special characters" pop-down menu above the text editing area, and the old special characters insertion interface below the text editing area, which looks like this:

Insert  – — … ‘ “ ’ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ √ ← → · §   Sign your posts on talk pages: ~~~~ 
Cite your sources: <ref></ref>

Shouldn't there be one special character interface to rule them all? -- Beland 12:20, 13 August 2009 (UTC)

As old toolbar does not have special characters feature built-in, we do not want to remove the one below the text editing area until the new toolbar is widely accepted and become default eventually. Special characters below the text edit area is configured by administrators. See the blog post for the similar discussion. --Shuhari 02:03, 12 October 2009 (UTC)

Text is lost when I navigate away from edit screen

In the Beta, when I navigate away from a page I'm editing and then navigate back, all the changes I made are lost. In monobook, that doesn't happen. This is absolutely infuriating, especially for newcomers who are likely to click on the links near the submit button to find out how things work, only to return and have their edit disappear.--Ragesoss 03:44, 14 August 2009 (UTC)

Tutorial link on sidebar proposal

I think that there should be a minimally invasive link to the Wikipedia tutorials on the left-hand sidebar. Now that it is cleaned up a bit, there is an opportunity to add a single line that says something like "Wikipedia Tutorial," "Getting Started," or something along those lines. Obviously when new users sign up they are directed to the tutorials, but after they begin editing and find that other questions come up, it would be a pain to navigate back to the tutorials without strong knowledge of the ins and outs of Wikipedia. I think that a link on the new, cleaner sidebar would be helpful. Thoughts? --Jeff Grimes 18:23, 14 August 2009 (UTC)

Great idea. The reorganization of left navigation bar has not been visited yet, but it is something that the usability team wishes to tackle in the near future. --Shuhari 01:19, 16 August 2009 (UTC)

Font size for references

How is Acai treating references and footnotes differently? The font size for anything in the references section (I assume everything generated by cite.php) are larger than they were before. The text in the references section is now almost as large as the main article text. What's the reason behind this? I prefer the smaller size - I can skim the references quicker, and the extra whitespace makes it more clearer and visually appealing. Other thoughts? - 94.194.23.112 01:03, 16 August 2009 (UTC)

The Vector skin in Acai release is not treating the font size of references and footnotes differently from the current default skin, Monobook. --Shuhari 01:26, 16 August 2009 (UTC)

Then why is it different on the English Wikipedia? Compare them side by side, and the difference is obvious - I'm using Firefox 3.5. - 94.194.23.112 09:21, 16 August 2009 (UTC)

In IE8, the text size is the same. But IE8 doesn't even render the columns properly for {{reflist|2}} on English Wikipedia, on Vector or Monobook. - 94.194.23.112 09:29, 16 August 2009 (UTC)

Older computer compatibility should be tested

• Releases/Acai/Compatibility_Matrix focuses on browser compatibility, without saying what kind of computer was used to perform the test, whether a new fast computer, or an old slow computer. See what I wrote on Toolbar#"Script_is_too_slow" error message.

• Main Page invites people to "Help us complete our browser compatibility testing". But how do you know if people with an older or any special kind of computer are able to navigate on this main page and browse this usability.wikmedia.org wiki ? Should not at least one part of this website be free of all kinds of new software, and display simple messages in simple html pages in order enable people with a variety of computers to take part in the survey and share their experience ? I am still looking for a way to opt out.

• If the decision is taken to implement new software in a way that makes Wikipedia impossible or increasingly difficult to browse on an older computer, this decision should not be taken without some kind of assessment of what kind of computers and what kind of people will be affected. Teofilo 09:41, 16 August 2009 (UTC)

• Another suggestion would be to use a "simple html mode" as they do on Google Books. At the bottom of the main page on Google Books' main page you can click on the "html mode" link, which will subsequently add "&output=thml" to all the URLs you visit, which has the consequence of never showing at the same time more than one page of the book you are reading. Teofilo 06:20, 17 August 2009 (UTC)

Extended tabs are not hidden in Opera 9.63

Under Opera 9.63 (Linux) the extended tabs (move, watch...) are displayed when the mouse is on the small arrow, but are not hidden when the mouse go out of the frame. ~ Seb35 [^_^] 09:49, 16 August 2009 (UTC)

monobook

My monobook does not work in BETA. It added tabs to the header line to do some work and added fields to the side bar to do some other work. Both are not present in the BETA. Since I received my monobook from another writer and do not do such coding myself, I am not sure how to make it compatible with BETA. Help please. 98.244.37.118 17:16, 16 August 2009 (UTC)

"Bad" jump when starting to edit

One thing that has annoyed me about the new beta is a problem which happens just after I click on the Edit tab. The editing page appears to load, I start editing some wikitext, but then the page finishes loading and the text cursor jumps to a different part of the text. One time I was in the middle of typing a word, and the first half ended up in one part of the article, and the second half farther down in the article. -- Beland 00:58, 17 August 2009 (UTC)

Yeah I dislike this too. If you disable the "enhanced editing toolbar" in Preferences though, you can work around it. —en:User:Jengelh Aug 22 09:43:23 UTC 2009

Problem when using the Beta version of Wikipedia when using internet explorer 8

The user gadgets and the qui does not work in the beta version of wikipedia using Internet Explorer 8. However, it works in the nonbeta version of wikipedia and opera mini. The Qui gadget, the purge clock, and the * purge link does not work. However, other gadgets worked perfectly. --Tyw7 11:48, 17 August 2009 (UTC)

I now found out the gadgets work ONLY when I enable these options:

• The JavaScript Standard Library, a compatibility library for browsers that lack full support for JavaScript 1.6. This includes Internet Explorer, Opera, and Safari 2.
• Compatibility function to run scripts only tested on Monobook on the new Vector skin. Required for using Twinkle or Friendly (along with many other scripts) with the Vector skin.

--Tyw7 12:48, 17 August 2009 (UTC)

Compatibility with mobile phones ?

What should we do to ensure our materials are available to the growing number of people who access the internet only through mobile devices?

Sue Gardner

As phone screens are becoming larger and small computers such as netbooks are distributed from network operators with broadband modems, it is difficult to target perfect read/edit experience for entire range of mobile devices. While contents are accessed through small screens of mobile phones in developing countries, screens size and resolutions on smart phones are giving more and more standard web browser experience. While people in developed world have access to Wikimedia contents through both computers and mobile devices, majority of people in developing world only have access to mobile phones. For the latter group, being able to read articles is the first priority. For smart phones, cross-browser testing needs to include these devices. --Shuhari 06:04, 23 August 2009 (UTC)

Have we planned to review how the new beta works on mobile phones ? Is it more convenient or less convenient than the old monobook ?

Teofilo 11:34, 20 August 2009 (UTC)

The usability team did a spot check of Vector on iPhone. Please help testing on other devices. :-) --Shuhari 05:18, 23 August 2009 (UTC)

Font sizes are at an all-time low

[vector.css] It's small — a mere 10pt - . Why can't people design a stylesheet so that the large part of the text (i.e. that of an article) is the same size as the browser default? (After all, that's the size the user sets for what he thinks is an acceptable standard size.) Also, "em" and "%" should be used instead of "px" and "pt". —en:User:Jengelh Aug 22 10:10:27 UTC 2009 [8]

Placement of the buttons at the top

Hi, the placement of the buttons is awful when the size of the browser window is too small: File:Screenshot_for_Acai_feedback.png. Firefox 3 and Linux, screen resolution 1024x768 but the window size is only 960x700 when maximized with the Window Manager I use (WindowMaker). On the screenshot, the window is even smaller. On some pages, even when maximized I have buttons partially or completey overlapping, for example on the german wikipedia on a page with an unverified version (buttons: Seite, Diskussion -- Artikel, Entwurf, Entwurf bearbeiten, Versionsgeschichte, [v] -- [search field], Artikel, Volltext). Polletfa 12:03, 22 August 2009 (UTC)

Vector's tab display for German in resolution less than 1024x768 is a challenge, as german words are long and widen the tab widths. The usability team is looking into the way to shorten the search box in the upcoming release in September. Hopefully, this change will ensure better navigation for languages with long words and double-byte languages. --Shuhari 06:15, 23 August 2009 (UTC)

That will never be enough to solve the problem with small screens, when the user browses in a small (non-maximized) window or when using a big zoom, like someone reported 2 sections below. Even in such cases, the elements shouldn't be overlapping like that. Other websites with floating elements have a "minimal size" under which the floating elements stop adapting to the window size (for example the Gmail interface). Then the user needs to scroll to see everything, but no element of the interface stays hidden behind another like it does with Acai. Besides, even on a 1024x768 resolution, the search field would have to almost completely disappear (for example on the german "Wikipedia talk" pages, because of the "Projektseite"/"project page" and "Abschnitt hinzufügen"/"add topic" tabs), especially if a caption is added to the [v] button (I heard it was planed to call it "Actions" or something of the sort). Polletfa 17:06, 23 August 2009 (UTC)

Location of warnings

Some edit warnings (most notably the one about lost session data) appear on top of the preview; if the preview is set to be below the editbox, they appear there (and off the screen for a typical monitor size). This has got nothing to do with Acai (does the same in all skins), but it would be nice if you could fix it somehow. It can be very confusing when one tries to save and the edit box comes back without any visible feedback. --Tgr 21:34, 22 August 2009 (UTC)

Headings and zooming

The acai heading, when zooming-in (ctrl+'+') more than a certain percent, is rendered strangely. I tested the english site on 800x600 (over 125%) and 1024x860 (over ~150%) resolutions on winxp, IE7 and Firefox 3.0.13. The behavior of the toolbar in the 2 browsers is different: In IE7, zooming in take the "Page|Discussion" to the left, behind the logo. In Firefox3, the "Read|Edit|.." is pushed by the searchbar and go behind the "Page|.." part.
Means that part of the toolbar is unaccessible while in extreme/moderate zoom-in. Unlike the regular toolbar that has tabs that grow in size while zooming-in. Thank you, --132.72.151.209 09:00, 23 August 2009 (UTC)

page loading : CPU 100% during 8s

Hi

With Acai, my browser (behind a proxy) on page load, use 100%CPU during about 8s for each page to load (the perfmon indicates 100% CPU used by the unique IEXPLORER process). The configuration of my computer is (basics): Celeron 2.40GHz processor, 504 Mbytes RAM, 8Mbytes/s (IP) access, Microsoft WindowsXP SP2, Internet Explorer 6.0 SP2. Javascript onload execution ? I Hope I'm the only one having this problem, but I quit açai for now.

With the "normal" version, it tooks 1 to 2s at least for the same pages.

Testing Acai again later, but the Strategic Planning project use it by defaults. That's quite boring.

-- User:Eric_schreiner ^talk 14:22, 24 August 2009 (UTC)

Login should not navigate to another page

When a user clicks on the link "Log in / Create account", currently this takes the user away from the current page and loads a completely new page. Instead, it should open a pop-up inside the same page, that has a box for the user name and the password. Only if the browser does not have Javascript enabled should it navigate to the login page. -130.49.221.7 08:21, 27 August 2009 (UTC)

Agree. FT2 12:12, 1 September 2009 (UTC)

We're looking at Wikia's AjaxLogin extension, which does exactly this. --Catrope 09:33, 12 October 2009 (UTC)

Mini toolbar idea

Not sure where this belongs, but there is one innovation I would like to see in the interface.

I wouldn't mind seeing a very slim full-width (non-scrolled) top or bottom bar as an interface option. This bar would host user-selected items from a short list, that the user wants visible at all times. Examples of items that might be "hosted" on this bar if the user wants are shown in the mockup:

FT2 18:10, 31 August 2009 (UTC)

An editor script fails on Beta version

Each time I load a page that uses the new Beta editor, like the new Wikipedia Beta editor or even this page editor, a JS script crashes and Firefox shows me the following message:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

http://server, like es.wikipedia.org or usability.wikimedia.org/w/extensions/UsabilityInitiative/js/js2.combined.min.js?3:a number, like 9 for Wikipedia or 140 for this wiki

I've found this bug today, because a few weeks ago I opened the new Beta editor and nothing crashed, and all the scripts used to work fine.

--Danielrm93 16:30, 2 September 2009 (UTC)

How can I install "Acai user preference" on my own wiki?

Dear,

"Acai has been deployed to Wikipedia and all Wikimedia sister projects as a user preference since July 1 2009. The following features have been targeted. You can try it out by clicking "Try Beta" link on the top of every page."

Very nice!

How can I install the Acai user preference on my own wiki?

-- Nfengone, 82.239.68.35 23:03, 2 September 2009 (UTC)

I'm also interested in utilizing this on my own MediaWiki installation. Is this available for public use on other wikis?

--Michael.Eddie 15:32, 4 September 2009 (UTC)

One way to get it is by running the most recent development version of the wiki, available via SVN. That includes the Vector skin. You can try downloading just the Vector skin from SVN too (instructions are on that page) but I'm not sure if it is backwards compatible with Mediawiki prior to 1.16 since I haven't tried that. Hope that helps! --Andrew

Will Acai be part of one of the next MediaWiki versions? --95.113.17.143 09:10, 27 September 2009 (UTC)

Acai is split into two parts: the Vector skin and the UsabilityInitiative extension. The Vector skin is part of MediaWiki core; you can obtain it by running the latest SVN version or by upgrading to 1.16 when it's released. The UsabilityInitiative extension is available from SVN as well, but it's not compatible with MediaWiki 1.15 and is under continuous development, which means it also includes Babaco features at this point. --Catrope 14:03, 27 September 2009 (UTC)

Basically, it's not a good idea to use the UsabilityInitiative extension until it's finished next year.

Tab order

Sometimes the tab order doesn't work: pressing tab in the edit box does not bring you to the summary field, but to one of the links in the legal text just below. This can be very disorienting, if one is used to sending by pressing tab and enter (which in this case would navigate the browser away to creativecommons.org, though the unsaved text popup feature prevents that). The effect is not deterministic, so maybe the side effect of some script? --Tgr 08:54, 7 September 2009 (UTC)

Cursor/edit history weirdness

When you click on the edit window while it is loading and start typing, part of the input goes to the beginning of the text, and the rest to the end. The part at the beginning seems to exist outside the edit history (pressing ctrl-z repeatedly will not remove it). Very annoying for power users. --Tgr 12:19, 7 September 2009 (UTC)

I think it happens when you click on the edit box and start typing while some scripts have not fully loaded yet; probably some script tries to put focus on the edit box. It should check whether it already has focus. --Tgr 12:29, 7 September 2009 (UTC)

Agree, this is _VERY_ annoying and has happened to me quite a few times, see for example here. The two colons in front of the section heading were inserted because I already started typing the indentation colons when the script switched back to the top of the edit box for a split second, resulting in the colons destroying the section heading and missing for the indentation. This is just one case where I did not realize this until after I saved. Please fix this. Thanks and regards, --ChrisiPK 18:18, 17 September 2009 (UTC)

addPortletLink problem

Addin new tabs through addPortletLink does not work on special pages. (I have a script which adds a tab linking to the enwiki vequivalent, which is pretty useful when doing localization.) --Tgr 17:07, 12 September 2009 (UTC)

Image margin problem

Right-floated images have no left margin, the text touches the border. Left-floated images are better, but they still overlap list bullets (list-style-position: inside would help). See both problems on the screenshot below (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 1200x800) --Tgr 17:20, 12 September 2009 (UTC)

Additional info: it works correctly with IE 7, but it's wrong with IE 8. --El Mexicano 17:49, 15 September 2009 (UTC)

Localisation of feedback form

This is a copy of a message left on main page talk. There doesn't seem to be much activity on that page so I am copying to here in the hope that someone will respond. If there is a better place for this issue please tell me.

"The intro to the feedback form does not at present say which language any respondent should use to write their responses. All the messages making up the feedback form are included for translation. But if the questions are all translated then you can expect narrative answers to be provided in the language of the question. Are you translating any non-English replies at all? Are you binning any non-English replies? If you can only cope with narrative replies in English then we should add a note to that effect to the intro message. If feedback is being received in other languages then could you let the translators at translatewiki.net know which are OK to use? With best wishes."

For additional comments please see translatewiki.net. Lloffiwr 19:08, 21 September 2009 (UTC)

Falta de interesse... causa o atraso em que se vive.

Sou Brasileiro, sim e me orgulho, mas devo críticar construtivamente a falta interesse de nossos representantes pela publicidade, na Cidade de Nova Cantu_Pr, existe uma boa estação de RADIO_FM, estive na região e a ouvi, agora tento localizá-la, usando os recursos de pesquisa da WEB. e não encontro, gostaria de num tempo bem curto, obter não só o endereço da radio, tambem o mapa e tudo que for possivel da referida cidade contida aki nas paginas do MUNDO.

Font sizes

Why are some font sizes in Vector so small? E.g. text in <code> tag or in diffs. I think they should be the size as in Monobook. Svick 19:27, 5 October 2009 (UTC)

Are you referring to Norwegian Wikipedia and Wikimedia projects? Or English wikipedia? --Shuhari 22:08, 3 November 2009 (UTC)

Right part of page tabs more to the centre

I think the right page options bar next to the search is to far at the right. You have to move the mouse across the whole page to get there. Especially on wide screen displays the links are far to much at the right corner. So why don't place them between the left links (Page + Discussion) and the search field? I made a graphic how it would look like. I am afraid I was not able to upload it here but you can take a look at it here. --Danwe 20:02, 11 October 2009 (UTC)

Losing edits with beta interface

While editing pages with the new "beta" interface, the interface often gets into a state where additional editing inside the "edit window" becomes impossible. The cursor cannot be placed within the edit window in this state. This state appears to occur after using the main scrollbar on the browser window, and indeed it has just occurred as I entered this comment! I am using Internet Explorer 8.0. The problem does not occur with the previous interface. Easchiff 11:19, 3 November 2009 (UTC)

Update: this problem does not seem to happen with the Firefox browser; I'm using version 3.0.1 . Easchiff 20:04, 3 November 2009 (UTC)

Will look into what is causing this problem. Do you mean "monobook" by the previous interface? --Shuhari 20:56, 3 November 2009 (UTC)

Bug 21401 is filed. --Shuhari 22:03, 3 November 2009 (UTC)

Thanks. As you surmised, I have been using the default monobook skin prior to my experiments with the new interface. Cheers, Easchiff 00:04, 4 November 2009 (UTC)

Stars

There is a problem in the links with others wiki : the stars witch saw the FA or the GA wasn't schown. --Tpt 06:29, 9 November 2009 (UTC)