Talk:Releases/Babaco/1

How/Where to test Babaco?

Hi. Will this release be available for testing here or maybe on test.wikipedia.org? I'd like to test some stuff and be ready for the next release with some of the scripts we use on pl.wiki. --admin on pl.wiki Nux 14:07, 16 September 2009 (UTC) BTW. New features looks very promising :-)

Babaco features are staged and being actively tested in the prototype environment. --Shuhari 21:14, 16 September 2009 (UTC)

new version text size

Some of the text seems to big, and other comments: n:Wikinews:Water_cooler/technical#Vector_problems_after_mediawiki_update (permalink). In paticular, the text size of stuff using jsMsg() (like the this page is now watched message, lots of gadgets) is way to big. On wikinews we shrunk it a bit in css.[1] Bawolff 02:07, 17 September 2009 (UTC)

p.s. line height is weird if text wrapped in div but not p. See http://en.wikinews.org/w/index.php?title=Wikinews:Sandbox&oldid=883132 Bawolff 03:40, 17 September 2009 (UTC)

We added css to wikinews to compensate (div#bodyContent {line-height:1.5em}) so my example no longer works. See this example on pedia. Bawolff 19:37, 17 September 2009 (UTC)

js bug

$j("#edittoolbar-link-tabs").tabs is not a function, EditToolbar.js?30 (line 792), here. Firebug says it is a function, so probably it is called before jQuery UI has been loaded, or maybe the two jQueries (both AjaxLogin and mwEmbed load it) clash somehow. --Tgr 07:21, 17 September 2009 (UTC)

This has to do with the UsabilityInitiative extension not working properly with JS2, causing it to forget to load jQuery UI. This has been fixed on all prototypes except sandbox.2 (on purpose). --Catrope 14:06, 27 September 2009 (UTC)

code font size

The small font for <code> is hard to read (FF3.5/WinXP, 1200x800). --Tgr 09:19, 17 September 2009 (UTC)

I second this. I had to add custom rule to my vector.css to fix this. Svick 07:44, 21 October 2009 (UTC)

Navigable TOC

The TOC is really cool. One thing I noticed though is that although the TOC changes as I move through the page, it doesn't scroll the scroll bar when I move into sections that aren't shown in the TOC yet.
--Ryan lane 13:44, 17 September 2009 (UTC)

That's fixed now --Catrope 19:08, 6 October 2009 (UTC)

Find and replace

When doing a find and replace, there isn't any indication that the find and replace is actually occuring. At first when I clicked the replace link, I thought it may have been broken because I didn't realize it was searching through the text. A progress bar would be really nice, especially for really large pages.
--Ryan lane 13:44, 17 September 2009 (UTC)

Multiple rows

Often you need 2 rows to define a unique string because of the line break(s), e.g. in table code. --Subfader 22:58, 6 October 2009 (UTC)

How to add new custom buttons?

Is there any document on how to add gadget buttons? Current version is destroying the toolbar to which some gadgets add their buttons. This make it worse then before as the toolbar seems to be available (#toolbar is available) and then it simply hides all buttons in it... Fucking annoying if you ask me :-/. Is there at least some way to know that the new toolbar will be loaded? Note: to know if it will be loaded is different then to know the users add it in preferences (new toolbar is not loaded e.g. on JS pages). --Nux 19:37, 25 September 2009 (UTC) PS: my previous post on pretty much the same topic

Calm down. Don't forget that this us still under development. New buttons will definitely be supported. --Mephiles602 20:31, 25 September 2009 (UTC)

The best documentation we currently have for this is our test script. --Catrope 19:55, 6 October 2009 (UTC)

Is there a way to call the content generation dialogs from javascript without enabling the new toolbar?

I want to get people on hu.wikipedia to test the new features, but the "enhanced" toolbar sucks so horribly without the opportunity for customization, no one is willing to use it. Is there a way to call the dialogs from javascript so I can bind those calls to buttons on the old-style toolbar? --Tgr 14:32, 2 October 2009 (UTC)

The advanced toolbar doesn't "suck so horribly without the opportunity for customization" because it can actually be customized, see the section right above this one. --Catrope 23:46, 26 November 2009 (UTC)

Navigable TOC when reading

I love thoses new features.

Still, I wish there was a TOC on the right when reading long pages. I use the TOC to find the section I want to read, then I may want to use the TOC again, to find another section I would like to read. I am obliged to return to the top of the page, and return to the article afterwards, and so on and so forth. A navigable TOC always on the right would be really helpful. Dodoïste 15:42, 3 October 2009 (UTC)

Why is the cursor before the signing tildas ?

Why is it that when I sign the cursor comes before the tilda? What is the rational for that?--41.235.170.56 21:15, 3 October 2009 (UTC)

TOC sidebar loading problem

The TOC on the right of the edit screen is a cool feature, but it loads slowly, so you might start typing before it appears, and when it does, it rearranges the text in the edit box, which can be rather disorienting. Can't you just put it there from HTML (with some default text saying you need javascript enabled)? Pretty much everyone has JS nowadays, and it is a preference option, so if someone does not, they wont enable it anyway.

(Of course if you could just make it appear faster, that would work, too.) --Tgr 10:14, 4 October 2009 (UTC)

I agree.

Plus, on long pages, it reloads everytime I type something, even when it's not related with the TOC. When it reloads, I have to wait until it finishes to reload, and then type a few more characters, then it reloads again, I wait, I type a few more characters... It's extremely annoying. I'm using Opera 9.64 with Vista. Dodoïste 10:39, 4 October 2009 (UTC)

You might consider to remove the automatic reloading of the TOC. The user owns the interface. The user should be able to decide himself when to reload the TOC. Please provide a "reload" (refresh?) button for the TOC. That would be much better for slow connexions, and browsers that are slow with JavaScript. Dodoïste 18:55, 4 October 2009 (UTC)

The TOC doesn't reload on every keypress. Rather, it waits until you've stopped typing for a second, then reloads. Reloading the TOC also does not use your connection in any way, so slow connections don't suffer. Also, I recommend ditching Opera 9.64 in favor of Opera 10; 9.64 is slow and buggy. --Catrope 18:53, 6 October 2009 (UTC)

That's right. What I mean, is "a second" is way too short. On short page it's okay because it reloads instantly. But it is really impossible to perform an edit on a long article like système électoral.

The user should have more control on the TOC reloading. Most users like the TOC, but don't want it to reload unless they asked it te reload.

I am using both Opera 9.64 and Opera 10. Technically, of course Opera 10 is better. But the design of Opera 9.64 is much better. So I'm using both of them. And I do have loading problems with the TOC regardless of the browser. Dodoïste 22:20, 6 October 2009 (UTC)

Link insertion

The new link insertion tool is pretty nifty, but it lacks a simple feature: decoupling of page title and link text. A typical user might select a word to link, bring up the link tool but wants to select a page title without changing the link text. I actually thought the 'broken'/'fixed' link icon could be used to do that. It wasn't very clear to me that it indicated if the page could be found or not. Husky 23:14, 4 October 2009 (UTC)

The link text changes to mirror the link target if they start out the same. This stops when you change the link text. I agree that this feature could maybe use some refinement, but I can't think of any concrete improvements. --Catrope 23:41, 20 November 2009 (UTC)

WikiEd

Hi, the Babaco release does not seem to be compatible with the wikiEd tool. Having the wikiEd enabled in the preferences, the link insertion dialogue and the navigable table of contents next to the edit window do not work. --Eleassar 07:34, 6 October 2009 (UTC)

I had the same problem. Couldn't get bold or italic to work either. Have disabled Babaco for now. --AlexandrDmitri 05:41, 10 October 2009 (UTC)

Edit TOC in Google Chrome 3

As I stated on the Babaco Compat Matrix talk page, the edit TOC completely fails in Google Chrome 3; it's as if it doesn't exist. Checking the error console doesn't show any errors. Dinoguy1000 17:58, 6 October 2009 (UTC)

The usability tech team is currently looking into the issues. Feel free to file a bug case. --75.101.56.124 21:24, 6 October 2009 (UTC)

Bug in active section selection routine in navigable TOC

Hi, I've enabled the navigable TOC for my account on the English Wikipedia. I was editing my talk page, and I noticed a minor bug in the TOC.

I was editing the entire page rather than individual sections, because I had multiple comments to which to reply. Since the last time I had edited the page, first one user had added a section without the proper header syntax, thereby adding it to the previous section, then another user had properly added a new section.

Example of where the bug was found

== section foo x ==
blah blah blah
== section foo y ==
blah blah blah
== section foo z ==
blah blah blah

== new section ==
<!--section added during the edit, manually-->

blah blah blah <!--was typing here-->

== section foo Ω ==
blah blah blah

I first edited the improper header to fix it, changing it to a normal level-2 header from some otherwise unadorned text. After that, while I was adding a reply in the new section, I noticed that, while I typed, the focus (the bolding of the selected section) in the navigable TOC changed to the section below (the last section) while I was typing, and changed back to the proper new section once I stopped typing. I was typing above the section header of the section below, so I found the behaviour incorrect—I was not editing the section below until later. Can this be fixed, please? Thanks, Nihiltres 16:32, 17 October 2009 (UTC)

A fix for this was deployed last Wednesday as part of a larger bunch of fixes. --Catrope 22:50, 20 November 2009 (UTC)

Navigable TOC does not work in Firefox 3.5

When I activate the navigable TOC and edit an article, it loads a grey box on the right side of the edit box where I assume the navigable TOC is supposed to go, but nothing appears there. I am using firefox 3.5 with Javascript and Java enabled. If it is a problem on my end and not yours, I would appreciate any guesses you might have as to the cause.--Danaman5 14:39, 20 October 2009 (UTC)

Thank you for reporting the display/loading issue of NTOC in FF3.5. We will investigate the problem and report back our findings. --Shuhari 14:50, 20 October 2009 (UTC)

I have the same problem, the box for navigable TOC shows, but is empty. But this happens only when I have the feature active and use the Monobook skin. As I think Monobook isn't supported for navigable TOC, I think the box shouldn't appear at all in that skin. Svick 23:33, 20 October 2009 (UTC)

The NTOC doesn't work under Vector for me either. Same thing, an empty gray box. The enhanced edit toolbar works, but not the NTOC. As a test, I disabled all of my add-ons in case there was a conflict, but that didn't solve the problem.--Danaman5 10:09, 21 October 2009 (UTC)

Interesting, it doesn't work under Vector for me either, with the same symptoms. I'm pretty sure it worked for me under Vector before. Svick 00:07, 22 October 2009 (UTC)

I have the same problem. But strangely, it only occurs in the Wikimedia Projects. It works fine on this site and the sandboxes.

Could this be the incompatibility with Twinkle mentioned below? --62.194.46.194 22:18, 20 November 2009 (UTC)

"Insert link/table" dialogs need some rtl/ltr changes

In the Arabic interface of "Insert link/table" dialogs, the headers, tabs and '×' button are shown left-to-right (see this) while it should be right-to-left in rtl languages (such as Arabic, Hebrew and Persian), and for the same reason, "Cancel" and "Insert" buttons need to be in the other side.

Also,"edittoolbar-tool-link-ext-target" text field needs always to be left-to-right (see the secreenshot) because all URLs are ltr.

Thanks for the great job.--OsamaK 17:10, 24 October 2009 (UTC)

Thank you for reporting the wrong orientation of link/table dialogues for RTL languages. The usability tech team will definitely look into the issues. Thanks. --Shuhari 00:49, 20 November 2009 (UTC)

NTOC conflicts with Twinkle and Friendly

In search of an answer to the NTOC problem under Firefox 3.5 that I reported above, I did some experimenting. It turns out that both the Twinkle and Friendly gadgets seem to be conflicting with the NTOC on en.wp. When I turn one or both on, the NTOC fails to load, when I turn them off, it does.--Danaman5 06:33, 1 November 2009 (UTC)

Oh, that explains it then. I'll try switching it off myself to confirm it... Yes, you are correct. I have the same problem. --Mephiles602 10:08, 1 November 2009 (UTC)

Add the ability to hide the NTOC

Hello, the field on the right, where the TOC titles appear, can I also make it hide? I often edit with two windows open, and then the field on the right makes the editor window quite small. --83.189.234.3 20:07, 1 November 2009 (UTC)

That's a good idea. Should it be done via the preferences or via a button on the edit page? --Mephiles602 22:35, 1 November 2009 (UTC)

A "Hide Contents" link has been implemented in trunk. I don't think it's currently on a sandbox anywhere, I'll make that happen tomorrow. --Catrope 22:20, 20 November 2009 (UTC)

Line break should not insert "<br />"

The line break button currently inserts <br />, for XHTML compatibilty. As I'm sure you will agree, this is wrong for several reasons:

1. This is wikitext, not (X)HTML. The fact that it borrows some HTML tags does not change this.
2. One of the points of wikitext is to be simpler than (X)HTML and its cruft.
3. We're trying to make Wikipedia easier to use -- so let's drop the unnecessary punctuation that will make no sense to people.
4. The MediaWiki parser, in its desire to output XHTML transitional, is more than capable of sorting out the tags anyway. It totally reparses and regenerates them from scratch. " /" is unnecessary extra parsing work, as it's dropped during parsing and MediaWiki puts in a new one.
5. Wikitext should be stable. We shouldn't be trying to accommodate in wikitext for the latest doctype fad. E.g., MediaWiki uses completely different syntax when exporting as PDF.
6. XHTML is pointless anyway.
   1. MediaWiki serves as Content-Type: text/html, so browsers never invoke their XHTML parsers on it.
   2. That's lucky too, because there are plenty of ways to break MediaWiki's output that it can't defend against, but as I say, browsers don't care because they parse it as HTML.
   3. The above situation is not going to change since Internet Explorer doesn't have an XHTML parser. It can't even interpret the content type. If you serve as XHTML, it will show you an XML tree or offer a download.
   4. A big point of XHTML was to make parsing simpler for mobile devices. In the several years since as the irksome XHTML plague began to infect the Web, mobile devices have become so much more powerful and parsers have become so much more efficient, that XHTML is now an irrelevant quirk, that the misinformed masses think they need but do not.
7. <br> looks nicer.

I'm sure the smart and sensible developers of the editing toolbar will concur that <br> is the superior tag. Anakin101 00:34, 10 November 2009 (UTC)

Egads -- enwiki's extended toolbar has the same issue. :-( Anakin101 00:55, 10 November 2009 (UTC)

Looks like WP commits to XHTML in page source:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">

--Rogerhc 04:46, 14 November 2009 (UTC)

Page source has nothing to do with this, since any recognizable <br> (even with wrong slashes) is converted into <br /> in the output; the question is what to use in wikicode. Alex Smotrov 15:21, 14 November 2009 (UTC)

Rather than using either br or br/, why don't we use new wikisyntax, such as -v- to represent a line break? --Mephiles602 11:06, 9 January 2010 (UTC)

"Discuss" instead of "Discussion"

I suggest changing "Discussion" tab to "Discuss" to make all tab names refer to a verb (read, edit, add, view, move). This will be more notable in languages that have clear differences between verbs and nouns that make it, somehow, inharmonious.--OsamaK 04:06, 12 November 2009 (UTC)

Are you sure ? The "discussion" button leads to the discussion page, and the list of discussions. A reader might come on the talk page only to read the comment, not to discuss. The "discussion" button does not creates a new topic. You suggestion might be misleading on the action the user makes. :-) Yours, Dodoïste 22:22, 12 November 2009 (UTC)

The Page/Discussion tabs are not intended to be actions ("Page" isn't a verb either). The action tabs (with verbs on them) are on the right, while the namespace tabs (page and discussion) are on the left. This distinction was made intentionally, partly for the reasons mentioned above by Dodoïste. --Catrope 22:22, 20 November 2009 (UTC)