[00:03:30] <nkomura>	nimish_g, time to meet
[00:20:35] <YaronK>	nimish_g_ (or anyone else): what do you think of this?
[00:20:37] <YaronK>	http://discoursedb.org/wiki/Template:Good_XML
[00:21:33] <nimish_g_>	YaronK, nice!
[00:21:35] <YaronK>	The colors are hideous, but I couldn't think of another way to make the information recognizable... maybe it would be recognizable even in black-on-white.
[00:21:55] <YaronK>	Really, even the colors? :)
[00:22:17] <nimish_g_>	the colors are fine for now, we can play with them later....do you think you could put tabs in to show the level of depth?
[00:22:58] <YaronK>	Alright.
[00:23:18] <YaronK>	Yeah... let me give it a try.
[00:27:01] <nimish_g_>	so parameter would have 1 indentation and label
[00:28:41] <YaronK>	Okay, try refreshing now.
[00:37:27] <nimish_g_>	cool, looks good
[00:38:24] <nimish_g_>	and it does the same thing with "type" and all those other fields right?
[00:40:27] <YaronK>	Er... no.
[00:40:41] <YaronK>	What other fields/tags/etc. should it handle?
[00:41:37] <YaronK>	I thought the "<app>" tag, for instance, shouldn't get handled by this "printer" thing.
[00:43:06] <YaronK>	I can definitely add a printout for the "type" attribute... although wouldn't that contradict the purpose of "type"?
[00:43:16] <YaronK>	Something to talk about on Thursday, maybe.
[01:02:24] <nimish_g_>	YaronK, sorry, we're in a meeting, but the purpose of the tool should be a pretty visual way to see all the information in the XML, including 'type'.  'app' might make sense to make lighter
[01:02:52] <nimish_g_>	but it should all still be visible
[01:03:03] <YaronK>	I'm pretty sure Trevor thought that <app> shouldn't be included...
[01:03:34] <YaronK>	I agree that there's a certain logic to displaying everything on the screen, though.
[01:04:19] <YaronK>	That's my recollection from our call last week.
[01:05:13] <YaronK>	As for 'type' - if that attribute were in there, wouldn't that mean that the XML can't be parsed by the TemplateInfo extension, though?
[01:05:38] <YaronK>	This gets to the heart of what I don't understand about the 'type' attribute.
[01:11:38] <nimish_g_>	I mean the other tag we had, like what kind of semantic type the parameter is
[01:11:43] <nimish_g_>	what did we call that tag?
[01:12:02] <YaronK>	Oh, that one, okay.
[01:12:58] <YaronK>	Actually, that's not in the specification - we decided that every field was untyped.
[01:13:22] <YaronK>	There are, however, <options> and <option> tags that I forgot about.
[01:14:23] <YaronK>	I'll add those in, but what about the <app> tag - should I add handling for that too?
[01:17:07] <nimish_g_>	yeah, it should handle the whole spec
[01:17:42] <YaronK>	Alright.
[12:43:35] <RoanKattouw>	GerardM-: FYI, LocalisationUpdate for extension messages had been broken since Nov 19, Fred and I have been poking at it for the last few days and it's working again now
[12:44:44] <GerardM->	You are kidding ...
[12:45:05] <GerardM->	what was the problem? what caused it ?
[12:45:35] <RoanKattouw>	Something went wrong when it was svn up, probably got interrupted or something
[12:45:59] <RoanKattouw>	This left the extensions dir in a locked state, but no one could unlock it or even see that it was locked because the script was running as root
[12:46:11] <RoanKattouw>	(noone means non-roots here)
[12:46:53] <RoanKattouw>	So when Fred poked at it, he found out about this, and transferred ownership away from root so I could unlock it
[12:50:19] <GerardM->	so it got unlocked and run again with the new owner ?
[12:50:47] <RoanKattouw>	Yes
[12:51:07] <RoanKattouw>	That was the day before yesterday; yesterday I noticed that Fred had forgotten to change ownership for the log file ^^
[12:51:16] <RoanKattouw>	So he fixed that, and it ran OK last night
[12:51:29] <GerardM->	so many messages were updated yesterday ...
[12:51:36] <RoanKattouw>	I think so
[12:51:42] <RoanKattouw>	Lemme look at the log
[12:51:44] <GerardM->	can you tell me how many messages there are and how many were added ?
[12:51:50] <RoanKattouw>	For now we only log the latest run
[12:52:18] <RoanKattouw>	Will look at that
[12:52:36] <GerardM->	(starting to write a blog about this)
[12:53:02] <RoanKattouw>	Last night, it updated 241 core messages
[12:53:10] <RoanKattouw>	(note that core wasn't locked)
[12:54:44] <RoanKattouw>	And 569 extension messages in total
[12:54:50] <RoanKattouw>	Will pastebin a detailed list
[12:56:27] <RoanKattouw>	GerardM-: http://pastebin.com/m7fe724dc
[13:00:22] <RoanKattouw>	GerardM-: Do you also need to know how many updated messages LU currently has?
[13:09:26] <GerardM->	RoanKattouw: yes please
[13:10:04] <RoanKattouw>	OK so do you want the number of messages translated in at least one language, or do you want the total number of translations in the system (in the latter case, one message can count more than once)
[13:10:30] <GerardM->	I would like the total number of languages
[13:10:41] <GerardM->	and indeed the same message may appear for many languages
[13:10:44] <GerardM->	that is correct
[13:11:05] <GerardM->	so the number of translations
[13:11:24] <GerardM->	(sorry for the confusion)
[13:11:28] <RoanKattouw>	The latter then
[13:11:36] <GerardM->	indeed
[13:11:42] <RoanKattouw>	Good, that's easier
[13:11:48] <GerardM->	:)
[13:13:28] <RoanKattouw>	35696
[13:18:49] <RoanKattouw>	GerardM-: Number of messages by language, sorted: http://pastebin.com/m34bd8c88
[13:22:55] <GerardM->	Roan, those numbers do not fit my expectations ... tonight was the first regular night and not the update since the 17th I assume
[13:24:13] <RoanKattouw>	It could be that some things got stuck
[13:24:28] <RoanKattouw>	LU is lazy, so if a msgs file hasn't changed in 24 hrs, it doesn't update
[13:24:58] <GerardM->	This is the amount I would expect for a day
[13:25:01] <RoanKattouw>	The dirty solution is to ask Siebrand to rebuild all msgs files for extensions, hoping that each of them will be changed
[13:25:12] <RoanKattouw>	The somewhat cleaner solution is I make LU forget when it last updated
[13:26:01] <RoanKattouw>	Or hm wait it works with hashes
[13:26:14] <GerardM->	clear the hashes
[13:26:20] <RoanKattouw>	You know it could be that the big major update happened the night before, but that night the logging was broken
[13:26:34] <RoanKattouw>	And we only keep logs for 24 hrs anyway
[13:26:34] <GerardM->	that is what I expect
[13:27:31] <RoanKattouw>	So given that it's hash-based, the lock trouble shouldn't cause any problems
[13:29:08] <RoanKattouw>	So sadly I don't have any change numbers for that big update, but you could attempt to verify that it happened by picking a message change between Nov 19 and Nov 29 or so
[13:31:43] <GerardM->	Roan, those precise numbers are nice to know but not important, getting all the messages in there is
[13:31:52] <RoanKattouw>	Exactly
[13:33:26] <GerardM->	likely they are already in there from yesterday when the logging is only not being able to log but not a problem with the update itself, it should not produce a much higher number
[14:03:48] <RoanKattouw>	It's now 24090 messages total, you're probably right about the decrease being because of removed messages
[15:06:00] <RoanKattouw>	hannes-tank: Can you generate png24's of all those lang-specific bold/italic icons like Trevor said and send them to me?
[15:06:40] <RoanKattouw>	Please use format-bold-F.png as naming convention
[15:06:40] <hannes-tank>	sure
[15:06:49] <hannes-tank>	?hhh
[15:07:02] <hannes-tank>	what about the other naming convention?
[15:07:11] <RoanKattouw>	What's that?
[15:08:45] <hannes-tank>	"toolbaricon_bold_F.png"
[15:08:58] <hannes-tank>	actually I dont mind
[15:09:30] <hannes-tank>	maybe we need to consider that those file are on commons
[15:09:42] <hannes-tank>	so maybe we should include "vector"
[15:09:46] <hannes-tank>	or anything like that
[15:09:53] <hannes-tank>	what do you think?
[15:10:16] <RoanKattouw>	My idea was to put those files in SVN, not on Commons
[15:10:40] <RoanKattouw>	I don't mind different names on Commons
[15:10:49] <RoanKattouw>	As long as the names in SVN follow the format-bold-F.png convention
[15:13:07] <hannes-tank>	I already put them on commons - thoug I habe to replace those files with the pngs file (cause they are jpgs at the moment)
[15:13:07] <hannes-tank>	http://commons.wikimedia.org/wiki/Vector_edit_toolbar
[15:13:35] <hannes-tank>	I ve send the png files
[15:15:00] <RoanKattouw>	Got them
[15:15:06] <RoanKattouw>	Yeah saw that page too
[15:15:19] <RoanKattouw>	I'll batch-rename then
[15:15:22] <RoanKattouw>	*them
[15:15:29] <RoanKattouw>	(on my PC that is, not on Commons)
[15:21:26] <RoanKattouw>	Ugh the icons look horribly blocky
[15:21:34] <RoanKattouw>	They should be 22x22 and generally be less blocky
[15:52:42] <hannes-tank>	what is "blocky"?
[15:56:20] <RoanKattouw>	hannes-tank: Lemme get you a screenshot
[17:35:14] <werdna>	anybody have any thoughts as to how I might make browsers remember changes to textboxes on back/forward
[17:43:35] <adam_miller>	werdna: update the hash whenever you make a change you want remembered?
[17:44:11] <werdna>	adam_miller: so if I update the fragment in the URL, then clicking the back button will take you to the same DOM state?
[17:44:15] <werdna>	in which browsers?
[17:44:56] <adam_miller>	you'd have to write code to handle the change, but i've done it that way before
[17:44:57] <TrevorParscal>	My understanding is that you must read the fragment in JS
[17:45:00] <TrevorParscal>	that's what I do
[17:45:15] <werdna>	hmm
[17:45:25] <adam_miller>	there's a jquery plugin that makes it easy to bind events to the change
[17:45:40] <werdna>	will it remember the text for me or will I have to do that myself?
[17:45:49] <werdna>	s/it/firefox and IE7+/
[17:46:02] <werdna>	basically the problem is that people accidentally click back or forward
[17:46:07] <werdna>	and then they go back and they get the original page
[17:46:14] <werdna>	without the AJAX-loaded textarea
[17:46:23] <werdna>	and, most importantly, they lose their changes
[17:46:50] <adam_miller>	hmm, maybe you want to interrupt the back/forward event then?
[17:47:00] <werdna>	I could do tat
[17:47:06] <werdna>	just add a confirmation to navigating away...
[17:47:16] <adam_miller>	here's the jquery plugin, if you want to look into that further http://www.asual.com/jquery/address/
[17:47:29] <werdna>	that may be an easier solution
[17:47:43] <TrevorParscal>	werdna: var url = document.location.toString();
[17:47:44] <TrevorParscal>	if ( url.match( '#' ) ) {
[17:47:44] <TrevorParscal>	  fragment = url.split('#')[1];
[17:47:44] <TrevorParscal>	}
[17:47:59] <TrevorParscal>	that's all you need to read the fragment
[17:48:08] <werdna>	yes
[17:48:20] <werdna>	I'm just thinking -- maybe I should just have a navigating-away warning
[17:48:59] <TrevorParscal>	take a look at this -> http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UsabilityInitiative/Vector/Modules/EditWarning/EditWarning.js?view=markup
[17:49:21] <TrevorParscal>	the onbeforeunload event is a strange one
[17:50:13] <TrevorParscal>	we could probably write a jquery extension that adds $(selector).unload( function() {} );
[17:50:27] <TrevorParscal>	that basically does the same black magic that the code I linked you to does
[17:50:27] *werdna 	nods
[17:50:37] <TrevorParscal>	then we can all use the unload thingy together
[17:50:44] <TrevorParscal>	without screwing with each other's bindings
[17:50:46] <werdna>	hmm
[17:51:25] <TrevorParscal>	allthough it's probably unlikely there would be 2 unload notices, the way the system is setup now, it's a debugging nightmare
[17:51:34] <werdna>	nod
[17:51:41] <werdna>	I'd really prefer to just use the same code as you
[17:51:47] <werdna>	and turn it on for everybody in LiquidThreads
[17:52:15] <werdna>	well it's either that or I can remember the textbox contents
[17:52:38] <TrevorParscal>	the code I showed you is present on all edit pages and works on wpTextbox1
[17:52:48] <TrevorParscal>	but that could be adjusted to make room for other uses
[17:52:54] <werdna>	yes, but not for people who aren't opted into beta
[17:52:59] <werdna>	and a few other sets of people
[17:56:17] <werdna>	hmmm
[17:56:36] <werdna>	I suppose I could test for the presence of EditWarning and self-disable accordingly
[17:57:29] <TrevorParscal>	i think I could refactor EditWarning to use a jquery plugin...
[17:57:33] <TrevorParscal>	that we could share...
[17:57:39] <werdna>	nod
[17:57:50] <TrevorParscal>	this mess with the script loader grr...
[17:58:01] <TrevorParscal>	I was hoping to have a unified way to include things for us and you....
[17:58:10] <werdna>	indeed
[17:58:38] <TrevorParscal>	maybe we will just refactor the script loader ourselves! he he he
[17:59:48] <werdna>	I think Tim would like that.
[18:00:02] <werdna>	I don't think Michael would.
[18:00:06] <TrevorParscal>	yes... that's true
[18:10:49] <TrevorParscal>	line 1544 of EditPage.php
[18:11:30] <TrevorParscal>	roan changed it from "  'class' => @$summaryClass,  " to "  'class' => $summaryClass,  "
[18:13:18] <TrevorParscal>	which means he removed the error reporting suppression...
[18:13:32] <TrevorParscal>	but, now the error is being reported (at least on my box)
[18:13:35] <TrevorParscal>	anyone else getting this?
[18:27:08] <RoanKattouw>	TrevorParscal: I added it, then removed it
[18:28:47] <RoanKattouw>	First the error was there, then I added the @ because I got fed up with it, then I accidentally committed the @
[18:28:51] <RoanKattouw>	So I self-reverted
[18:31:04] <RoanKattouw>	TrevorParscal: About the iframe src thing: a friend of mine suggested working around the IE bug using document ready on the iframe. I don't know if that'll work right, but I'll give it a shot
[18:52:18] <RoanKattouw>	TrevorParscal: "CodePress - Real Time Syntax Highlighting Editor written in JavaScript" --> dude?
[18:52:38] <TrevorParscal>	?
[18:52:41] <TrevorParscal>	What about it?
[18:53:08] <TrevorParscal>	oh
[18:53:09] <TrevorParscal>	ha
[18:53:17] <TrevorParscal>	that was still in there...
[18:53:21] <TrevorParscal>	changing
[18:53:56] <werdna>	RoanKattouw: I've used it before
[18:54:03] <werdna>	it's quite cool, but I had a bunch of problems with it
[18:54:18] <werdna>	in fact, I implemented a real-time collaborative code editor with it
[18:54:28] <RoanKattouw>	Ha
[18:54:35] <RoanKattouw>	According to Trevor and Nimish its code is horriblwe
[18:54:44] <RoanKattouw>	IIRC it has completely separate codebases for each browser
[18:54:49] <werdna>	yes
[18:54:51] <TrevorParscal>	werdna: we used a few bits of it as a preliminary model, then tossed those out failry quickly
[18:54:52] <werdna>	I hacked on it a bit
[18:55:38] <nimish_g>	yeah it just decided to use a different backend engine for every browser, including a totally empty one for khtml
[18:56:13] <werdna>	yeah it's awful
[18:56:31] <werdna>	I had quite a cool, but still bug-ridden, online IDE using it
[18:56:35] <RoanKattouw>	You know, while bugs like the IE-decapitates-DOM bug and the jQuery-overprettifies-regexes bug are very annoying and elusive, tracking them down and fixing them is very fulfilling :)
[18:57:00] <TrevorParscal>	RoanKattouw: agreed
[19:02:52] <RoanKattouw>	hannes-_-: http://yfrog.com/86blockyp
[19:03:14] <nkomura>	adam_miller: will you increase priority on this bug which we forwent from acai enhancement release?
[19:03:15] <nkomura>	https://bugzilla.wikimedia.org/show_bug.cgi?id=21538
[19:03:47] <nkomura>	it'd be good to patch production as this feature is highly visible to all beta logged in users
[19:03:49] <RoanKattouw>	That bug looks like it shouldn't take more than 10 minutes
[19:04:28] <nkomura>	that'd be another reason to fix it sooner than later
[19:04:57] <nkomura>	there are two css revisions from adam_miller which we haven't deployed
[19:05:12] <nkomura>	so we can schedule a patch altogether
[19:06:04] <nkomura>	hannes-_-: are you there?
[19:06:18] <RoanKattouw>	Aye
[19:06:25] <RoanKattouw>	Tim says we're mature enough to cross-review our own code
[19:06:42] <nkomura>	that's nice to hear
[19:07:30] <RoanKattouw>	So I guess that means I'll be reviewing and deploying some of Adam's code today, provided he can whip up that tooltip fix in the next 1.5 hrs
[19:08:11] <nkomura>	it does not need to be today RoanKattouw
[19:08:19] <RoanKattouw>	I know
[19:08:23] <nkomura>	and I would like CSS review to be done by TrevorParscal
[19:08:29] <RoanKattouw>	Good point
[19:08:44] <RoanKattouw>	So just FYI: I'll be in till 1 PM PT today
[19:09:03] *TrevorParscal 	takes CSS review tasks
[19:10:09] <RoanKattouw>	http://www.mediawiki.org/wiki/Special:Code/MediaWiki/59224 and http://www.mediawiki.org/wiki/Special:Code/MediaWiki/59254 IIRC
[19:10:47] <nkomura>	RoanKattouw: before you go offline, it would be good if you can discuss with adam_miller where you want to hand-off link dialogue work
[19:11:24] <werdna>	hi nkomura
[19:11:32] <nkomura>	hey werdna
[19:11:55] <adam_miller>	I'll get working on the watch/unwatch tooltip fix
[19:11:58] <RoanKattouw>	Good
[19:12:20] <RoanKattouw>	adam_miller: I'll throw some directions about the dialogs in y our face in the meantime, feel free to ignore them until you have time to read them ;)
[19:12:31] <adam_miller>	sounds good
[19:20:58] <RoanKattouw>	adam_miller: OK so the link dialogs had a bug where they froze up for a while, I fixed that today (was a bug in jQuery, filed upstream)
[19:21:20] <RoanKattouw>	That fix should be on the prototypes and sandboxes now so you should be able to look at the actual functionality again :)
[19:21:47] <RoanKattouw>	A list of things that were in Hannes's mockups but are not implemented yet is:
[19:23:08] <RoanKattouw>	* When the user enters an invalid title (containing characters like | [ ] ) the "Invalid title" message with a yellow triangle with a ! in it currently appear, but the textbox should also get a red border
[19:24:28] <RoanKattouw>	* Hannes wants the Insert button to be disabled when the target textbox is empty. This is easy enough, but the button should also /look/ disabled. This was not the case in the old jQuery UI theme we used, not sure what the status of that is in Trevor's new theme. If such an effect isn't there or doesn't look distinctive enough, poke at it
[19:25:36] <RoanKattouw>	* The text labels should be changed to be clearer. My suggestions would be "Target page or URL:" and "Displayed text:" respectively, but feel free to tweak or discuss
[19:26:03] <RoanKattouw>	That was the link dialog, now for the table dialog:
[19:26:32] <RoanKattouw>	* The label for the header row checkbox should say "Add header row" , i.e. explicitly use the word "add"
[19:29:54] <RoanKattouw>	* The table preview should be more distinctive from the rest of the dialog. Hannes shared a mockup for this on Nov 19th, then decided the preview area should die completely on Nov 25th. I don't agree with the latter, so we may want to discuss more. Feel free to keep your hands off for now if you don't like implementing stuff that we don't have a clear consensus for yet
[19:30:01] <RoanKattouw>	That's pretty much it for now
[19:32:06] <hannes-_->	yeah, you are right roan. the table dialog isn t set yet
[19:32:46] <hannes-_->	I ll try to restart the discussion, in order to makie some progress
[19:34:31] <RoanKattouw>	TrevorParscal: Tried document ready on the iframe, Firefox worked but IE crashed
[19:46:03] <nkomura>	hannes-_-?
[19:47:13] <hannes-_->	here
[19:47:18] <nkomura>	hey
[19:47:37] <nkomura>	so it'd be good if you can upload the mock-ups you did for dialogues to design section of our wiki
[19:47:58] <hannes-_->	ok sure
[19:48:10] <hannes-_->	I am doing a new one at the moment
[19:48:18] <nkomura>	so that it will be a share resource for the team and give preview to the community
[19:48:25] <hannes-_->	because paru and I were not 100% satisfied with the look of the preview
[19:48:42] <nkomura>	for the link or the table?
[19:49:30] <hannes-_->	table
[19:49:42] <nkomura>	adam will need access to link mock-ups
[19:49:53] <nkomura>	to start with
[19:50:08] <hannes-_->	he should habe them already, no?
[19:50:37] <hannes-_->	I ll send him again
[19:50:39] <nkomura>	not sure about others, but receiving mock-ups in email is not easy
[19:50:52] <nkomura>	lose track which version is the most current
[19:51:11] <nkomura>	it'd be best if it is available as a shared resource from the usability wiki
[19:52:05] <hannes-_->	though we don t want to share workinprogress files right?
[19:52:24] <nkomura>	we can share work in progress
[19:52:28] <hannes-_->	cause I was not sure if the dialog mockup were ready to go
[19:52:36] <RoanKattouw>	As long as we state clearly that it's WIP, I guess
[19:52:39] <hannes-_->	we can?
[19:52:40] <hannes-_->	ok
[19:52:42] <nkomura>	why not?
[19:53:18] <hannes-_->	hmm... I thought its unclever, cause people might freakt out... get confused...
[19:53:52] <hannes-_->	hey roan _ i just discovered a bug an sandbox 3 and 5 - concerning the collabsible NTOC
[19:54:06] <hannes-_->	is that your baby? or adams?
[19:54:15] <RoanKattouw>	Adam's
[19:54:17] <RoanKattouw>	What's the bug?
[19:54:34] <RoanKattouw>	hannes-_-: If we say it's WIP, that'll hopefully calm people down
[19:54:52] <nkomura>	hannes-_-: revising look and feel or link and table dialogs are things in the pipeline already
[19:55:05] <nkomura>	so it is fine to share them
[19:55:29] <nkomura>	we want to start sharing early conceptual work as early as we can
[19:55:33] <hannes-_->	if you have a small window and start the insert table dialog, the slider from the NTOC will be above the dialog, and it is clickable
[19:56:30] <hannes-_->	ok naoko, I ll upload it when I finished this new idea for the preview. I ll notify the team via email as well
[19:57:10] <hannes-_->	by the way: how can make that what you just did? I mean write a message to a particular person
[19:57:16] <hannes-_->	in RIC
[19:57:19] <hannes-_->	IRC
[19:59:21] <nkomura>	type a few letters and hit tab
[20:02:04] <hannes-_->	hmm doesn t work
[20:03:34] <nkomura>	it is like UNIX command
[20:03:47] <nkomura>	try typing just n and hit tab
[20:07:29] <RoanKattouw>	Try nk TAB instead, n TAB is ambiguous because nimish_g is also here
[20:11:30] <nimish_g>	RoanKattouw: oh that's awesome, I didn't know about that
[20:11:58] <RoanKattouw>	What, tab completion in IRC?
[20:18:16] <hannes-_->	roan, dud u set up the inserttable dialogs?
[20:21:53] <RoanKattouw>	Yeah they're on the prototypes
[20:22:00] <RoanKattouw>	You need to enable those dialogs in your prefs though
[20:24:17] <adam_miller>	RoanKattouw: can i use the js function gM() outside of the UsabilityInitiative extension?
[20:25:20] <RoanKattouw>	Where exactly would you use it?
[20:26:11] <nimish_g>	I think if you're working on michael dale's code, you can
[20:26:38] <adam_miller>	updating the tooltip on the watch link after an ajax call
[20:26:51] <adam_miller>	in skins/common/ajaxwatch.js
[20:27:22] <adam_miller>	i need to access the proper message there
[20:27:50] <adam_miller>	along with proper key command, if those change
[20:31:58] <RoanKattouw>	You can't use gM() there
[20:32:07] <hannes-_->	RoanKattouw: i was wondering why the preview looks different from a normal table. (the cells are bigger, more margin)
[20:32:14] <adam_miller>	i've figured that much out
[20:32:21] <RoanKattouw>	adam_miller: Where is the code changing the image then?
[20:32:35] <RoanKattouw>	hannes-_-: CSS issue, Trevor can probably fix that (or maybe Adam can)
[20:32:49] <adam_miller>	RoanKattouw:  wgAjaxWatch.setLinkText()
[20:33:00] <RoanKattouw>	Hm
[20:33:03] <adam_miller>	it's just changing a classname for the image switch
[20:33:07] <adam_miller>	so no translation needed
[20:33:08] <hannes-_->	ok cool. I just wanted to know
[20:33:12] <RoanKattouw>	Right
[20:33:41] <RoanKattouw>	adam_miller: What about wgAjaxWatch.watchMsg and .unwatchMsg ?
[20:34:32] <adam_miller>	that seems dodgy doesn't it? i'm trying to recall if I wrote that code
[20:34:47] <RoanKattouw>	Nope
[20:34:50] <adam_miller>	do we force non english wiki's to override that?
[20:34:53] <RoanKattouw>	Yes
[20:35:02] <adam_miller>	oh, well then i'll just add two more messages
[20:35:04] <RoanKattouw>	Before, there was no star, but a tab with the text "Watch", right?
[20:35:10] <RoanKattouw>	No need to add msgs I think
[20:35:15] <adam_miller>	right
[20:35:19] <RoanKattouw>	Why not reuse the ones already there
[20:35:29] <RoanKattouw>	Except of course if those are not what used to go in the tooltip
[20:35:32] <adam_miller>	because the tooltip is a bit more wordy
[20:35:56] <adam_miller>	'Add this page to your watchlist'
[20:36:06] <adam_miller>	'Remove this page from your watchlist'
[20:36:30] <RoanKattouw>	Ah yes
[20:36:39] <RoanKattouw>	Then you'd need to add them I guess
[21:02:25] <TrevorParscal>	RoanKattouw: how's it going?
[21:05:46] <nkomura1>	RoanKattouw_away: when you are back, let's update all prototypes including inline preview
[21:06:06] <nkomura1>	i'll start directing people to see the preview of citron
[21:13:14] <RoanKattouw>	TrevorParscal: I'm good. Uni's good. Only thing that sucks is driving tests, failed three of those so far :(
[21:13:29] <RoanKattouw>	nkomura1: OK so you want preview enabled by default on all prototypes? Dialogs too?
[21:13:30] <TrevorParscal>	owch
[21:14:14] <RoanKattouw>	My fourth (!) one is scheduled a few days before Christmas, there's bureaucratic consequences to failing that one
[21:19:13] <RoanKattouw>	nkomura1: Done. Preview and publish now enabled by default on all prototypes and sandboxes
[21:19:25] <adam_miller>	RoanKattouw: altering skins/common/ajaxwatch.js and includes/Skin.php. Do i need to bump any version numbers anywhere?
[21:20:05] <RoanKattouw>	adam_miller: $wgStyleVersion in includes/DefaultSettings.php for the former
[21:22:59] <adam_miller>	RoanKattouw: committed my bug fix for the watch/unwatch tooltip in r59680
[21:23:14] <RoanKattouw>	Nice
[21:23:20] <RoanKattouw>	Please close the bug as FIXED mentioning the rev number
[21:23:25] <RoanKattouw>	I'll review it tomorrow
[21:28:23] <RoanKattouw>	adam_miller: I assume the evil \[\] regex is to preserve the accesskey info? Is that code copied from anywhere?
[21:29:15] <adam_miller>	it's not copied from anywhere. why is it evil? educate me.
[21:29:27] <RoanKattouw>	+				wgAjaxWatch.watchLinks[i].title = ( newText == wgAjaxWatch.watchMsg ?
[21:29:35] <RoanKattouw>	Typo: watchMsg --> watchingMsg
[21:29:44] <RoanKattouw>	Well it probably works but it looks scary
[21:30:05] <adam_miller>	haha, you can suggest a better regex if you want
[21:30:06] *RoanKattouw 	wonders if and how the old interface handles the tooltip change
[21:30:27] <RoanKattouw>	Ha it doesn't
[21:30:28] <adam_miller>	i dont think the old interface did handle it
[21:30:38] <RoanKattouw>	Indeed
[21:30:58] <RoanKattouw>	Well it's kind of fragile, assumes the message itself doesn't contain [
[21:31:11] <RoanKattouw>	If it even contains just a [ , imagine how badly that messes up
[21:31:16] <RoanKattouw>	Worse if that [ has a matching ]
[21:31:57] <RoanKattouw>	I think /\[[^]]*\]$/ would be a bit better
[21:32:32] <adam_miller>	k, i'll test that and add it in
[21:32:38] <adam_miller>	why did you think watchMsg was a typo?
[21:32:49] <RoanKattouw>	Oh wait it's not
[21:32:52] <RoanKattouw>	I didn't read closely enough
[21:33:01] <adam_miller>	k
[21:33:22] <RoanKattouw>	(in detail, that regex requires that the matched [foo] string is at the end, and that the "foo" part doesn't contain a ])
[21:33:39] <RoanKattouw>	A cleaner one could be /\[.*?\]$/ I guess
[21:33:48] <RoanKattouw>	Assuming .*? works cross-browser
[21:34:46] <nkomura1>	RoanKattouw: thanks for updating the prototypes
[21:35:16] <RoanKattouw>	adam_miller: Still, the whole regex treatment it kind of fragile and scary. Maybe you could find out which function adds the accesskey info and simply rerun that after you've changed the tooltip, not sure if that can be done in a non-ugly fashion
[21:35:17] <adam_miller>	right. is there much variance in regex engines between browsers?
[21:35:31] *RoanKattouw 	tests .*? in Firefox and IE
[21:35:36] <adam_miller>	well Trevor has it being applied conditionally in vector.php
[21:35:39] <RoanKattouw>	Typically, if something works in both, it works everywhere
[21:35:58] <RoanKattouw>	adam_miller: No, I mean the JS that adds the [blah] thing to the tooltip
[21:36:31] <adam_miller>	right, i'm explaining why i did it that way instead of rerunning the accesskey info
[21:36:55] <adam_miller>	that function is being called conditionally in php
[21:37:06] <adam_miller>	so on pages with the wikieditor, it does not get run
[21:37:18] <adam_miller>	and the tooltip is rendered w/o the key comman
[21:37:54] <adam_miller>	so i could mirror that conditional in the js
[21:38:03] <adam_miller>	but this seemed a little more future proof
[21:38:10] <RoanKattouw>	OK .*? works in Firefox 3.0 and IE8, that's good enough for me for now
[21:38:25] <RoanKattouw>	Hmm
[21:38:31] <RoanKattouw>	Where in Vector does that happen?
[21:40:06] <adam_miller>	starts at line 391
[21:40:33] <adam_miller>	with a nice commentary
[21:42:05] <RoanKattouw>	Ah that [foo] addition happens in PHP
[21:42:12] <RoanKattouw>	Never mind what I said then, using a regex is OK
[21:42:49] <RoanKattouw>	OK guys I gotta go
[21:42:53] <adam_miller>	k, i'll commit this with your regex in a second
[21:43:43] <RoanKattouw>	OK
[21:44:08] <RoanKattouw>	Will review tomorrow, and probably deploy tomorrow after lunch (PT) if all goes well