[00:12:24] sorry RoanKattouw was in a meeting and missed you [00:12:41] SWEET [00:12:51] No worries [00:13:00] as long as we're following up (wait, are you still UP??) [00:13:21] seems as though the kerning effect on the font was coming from using the letter-spacing css comman [00:13:23] It's "only" 1:!3 [00:13:25] *1:13 [00:13:30] oh that's not too bad [00:14:00] if we did want to give more space to the letters in headings, do you know of any way we can do this with or without using that css command [00:14:05] without causing such problems? [00:14:27] YaronK: looks like you made it back to nyc alright [00:14:35] I don't know, ask Trevor (where is he?) [00:14:36] just in time for halloween! [00:14:43] hmm, he's out i think [00:14:46] i'll ask him [00:14:48] thx [00:17:05] Yes, I'm back in New York! [00:17:34] And I didn't get sick after the trip this time, as I usually do. [00:19:12] hi YaronK [00:19:30] Hi Naoko! [00:20:10] it was great to have you in the office [00:20:33] Yeah, it was great to be there. [00:21:15] I'm actually pretty far along now on the extension that was my "assignment". [00:22:08] It's an extension that will probably be called "Template Info". [00:24:22] is it something you were referring to as the replacement of semantic form? [00:25:33] RoanKattouw: [00:25:44] i have a quick question about some funky formatting showing up on a wikipage [00:25:44] http://usability.wikimedia.org/wiki/User:Juxn/howto#Photoshop [00:26:10] if you look in the third row.....any idea why "Scale it down to ...." has a box around it? [00:26:25] funny the same thing happened to a list i had made on a page about our UX/Usability study [00:26:56] parutron: That's caused by the first character on the line being a space [00:27:03] aaaah [00:27:05] good to know, thx [13:19:12] team ? [13:19:51] there are some concerns by people that there ideas on the Feedback page etc are not being read [13:20:52] It's 6:20 AM in San Francisco, so most people won't be getting this [13:21:11] yeah i know. [13:21:25] i'll repeat it later [13:21:39] Copy to Naoko when she gets in, I think she's the one usually reading feedback on usabilitywiki [13:22:08] i think just signing after reading or something might be a good idea. [16:39:15] RoanKattouw: good morning / afternoon [16:39:20] Morning [16:39:38] you saw my initial code for the iframe thingy... [16:39:46] thanks for the comment :P [16:39:49] Preemptive strike: PLEASE don't commit your grand extensions/WikiEditor restructuring before our next deployment [16:39:52] Yeah [16:40:01] The diff was confusing, I'll read the actual code some time [16:40:15] RoanKattouw: i'm not going to [16:40:31] besides, it's sort of just a shell for future merging [16:40:43] OK good [16:41:09] Just saying this because my life as our "release manager" (or at least the guy who does the merges) would be hell in that case [16:41:12] but you saw how that would play out too? [16:41:21] Yeah I like the new structure [16:41:22] ha ha [16:41:24] no worries [16:41:35] I just sstarted sketching that out cause I've been thinking about it for a while [16:41:37] Better integration between the modules we have now [16:42:09] BTW I delved in the chatlogs to find the issue that caused me to revert the editsection patch the other time [16:42:22] yeah [16:42:25] Turned out to be a CSS fail in Special:Specialpages [16:42:33] They had an

with a background-color [16:42:43] hmm [16:42:43] It used to be display:block; and span the width of the page [16:42:52] But after the patch it was display: inline; and wrapped in a div [16:43:07] I wanted to set the bgcolor on the div, but couldn't (screw you CSS for not having parent selectors already) [16:43:22] So instead I just added a display:block; on that h4 in the same rule that does the bgcolor [16:43:29] Not the most elegant solution ever, but it works [16:44:03] I also found an ancient bug (reproducible in MW 1.6!) where edit section links would show up for
Your text
and
Saved revision
on the edit conflict form [16:44:48] Hm we should nickname jquery.wik [16:45:00] iEditor.code.js "Trevor and the Magic " [16:45:07] <RoanKattouw> Sounds like a bad fairytale [16:45:31] <Ryan_Lane> morning all [16:46:11] <nkomura> morning Ryan_Lane [16:49:21] <Ryan_Lane> i'm going to be in and out most of the day. let me know if you need anything. i'll be checking messages [16:53:43] <YaronK> TrevorParscal and nimish_g: hi, guys! I have a few questions. [16:55:46] <YaronK> The biggest question for me is what to when one template (which contains a <templateinfo> tag) is embedded in another; whether that information is displayed when that other template is viewed. [16:56:00] <YaronK> (what to do) [16:57:15] <RoanKattouw> OK so template A uses template B. Which template are you viewing again? B? [16:57:26] <YaronK> No, A. [16:58:03] <YaronK> The problem is, one could imagine the cases where template B is being included specifically for the XML template information - in that case, you would definitely want to display it. [16:58:54] <YaronK> In other words, some templates could include a <templateinfo> tag that doesn't define themselves, but rather a template that they're meant to be included in. [16:59:30] <RoanKattouw> Maybe that should just be qualified as "that's crazy, don't do it"? [16:59:33] <TrevorParscal> YaronK: ok - so one template transcludes the other [16:59:38] <RoanKattouw> You mean building the templateinfo through transclusion? [16:59:46] <YaronK> Yeah, exactly. [16:59:58] <TrevorParscal> that's not a problem, because upon transclusion, the <templateinfo> tag is stripped out [17:00:47] <YaronK> Yeah, but if it's being transcluded in a template, it shouldn't be... [17:00:55] <RoanKattouw> TrevorParscal: Are you sure of that? [17:00:58] <TrevorParscal> why not? [17:01:07] <RoanKattouw> Oh wait yeah it would have to be [17:01:13] <TrevorParscal> RoanKattouw: that's not the current behavior, its the behavior we want [17:01:27] <RoanKattouw> Yeah, but I'm kind of doubting if that's possible with a tag [17:01:29] <YaronK> I guess it's fine - if it's transcluded from the "Template" namespace, keep it in; otherwise, leave it out? [17:01:41] <YaronK> The tag can check for what namespace it's in... [17:01:41] <RoanKattouw> No, why bother [17:01:56] <TrevorParscal> YaronK: well - any transclusion at all should render the <templateinfo> tag as nothing [17:02:02] <TrevorParscal> that's the whole idea [17:02:04] <RoanKattouw> If we don't want people to be able to build templateinfo with templates (which sounds deeply evil to me) we should simply disallow it [17:02:42] <YaronK> Okay, that's another possibility - TrevorParscal, didn't you mention the idea of having a template just for the XML definition? [17:03:42] <TrevorParscal> yeah, well that's if they really want the templateinfo XML in another place [17:03:47] <TrevorParscal> which sort of b [17:03:49] <YaronK> Right. [17:03:56] <TrevorParscal> breaks things possibly [17:04:17] <YaronK> Well, it violates the "rule" that an XML definition within a template defines that template. [17:04:37] <TrevorParscal> <templateinfo src="Template:TmpName/XML" /> ?? [17:04:54] <YaronK> Oh, that's interesting. [17:05:34] <YaronK> That could work... [17:06:02] <TrevorParscal> bascially we should say, <templateinfo> tags are parsed as XML and not preprocessed? [17:06:08] <TrevorParscal> can we even make that true? [17:06:42] <YaronK> I don't think you can ever not preprocess a tag function. [17:06:50] <TrevorParscal> the preprocessor handles the parser tag hooks and transclusion [17:07:00] <TrevorParscal> which order is what matters here... [17:07:12] <YaronK> Oh, yeah. [17:07:29] <YaronK> I don't know then. In any case, it's a bit of an unconventional approach. [17:08:01] <YaronK> That's why I always prefer parser functions. [17:08:45] <TrevorParscal> well, if we can't avoid people using transclusion inside <templateinfo> tags, then I guess that's that [17:08:51] <TrevorParscal> people will do whatever they like [17:09:47] <RoanKattouw> Oh wait [17:09:56] <RoanKattouw> Yeah I think tags are handled early rather than late [17:10:02] <RoanKattouw> Because their contents typically don't get preprocessed [17:10:04] <TrevorParscal> but what I am saying we have to do is make it so <templateinfo> tags are rendered as either a table when viewing the template like wiki/Template:TemplateName - or nothing when transcluded like {{Template:TemplateName}} [17:10:06] <RoanKattouw> Which is good in two ways [17:10:38] <TrevorParscal> RoanKattouw: if that's true, that would be awesome [17:11:15] <RoanKattouw> Aye, because it would be impossible to use template transclusion, parser functions and pretty much everything else inside <templateinfo> [17:11:31] <RoanKattouw> And we'd be able to weed it out before transclusion finalizes [17:11:47] <YaronK> Yeah, you can't put template calls inside tags. [17:11:52] RoanKattouw tries a quick tag hook that outputs nothing on a sandbox [17:13:01] <TrevorParscal> RoanKattouw performs mediawiki backflips and PHP karate chops [17:13:56] <YaronK> Here's a related question: do you know how a tag function can tell whether it was called from a transcluded page or not? [17:16:39] <TrevorParscal> Well, if $wgTitle is not the same as the title object of the template, that would be a pretty good indication [17:16:46] <TrevorParscal> RoanKattouw: what do you think? [17:18:47] <YaronK> I don't know if the tag function can know the title of the template, though. [17:19:15] <TrevorParscal> yes it can [17:19:35] <TrevorParscal> http://www.mediawiki.org/wiki/Manual:Tag_extensions#Example [17:19:56] <TrevorParscal> $parser argument can give you the "contextual title" [17:20:06] <TrevorParscal> compare that against the global title object [17:20:34] <YaronK> Ah, okay... [17:20:42] <TrevorParscal> and i think there's even more info in the frame parameter, but I don't know the details therein [17:24:26] <nkomura> RoanKattouw? [17:25:34] <YaronK> No, unfortunately, it looks the parser title always matches $wgTitle... [17:26:10] <YaronK> Or rather, it's the title being parsed. [17:27:22] <YaronK> Still, it would be possible to check the namespace, and only display info if it's in the Template namespace... [17:31:10] <YaronK> It's not an ideal solution, but maybe it's fine; the only templates it might mishandle are template-documentation templates. [17:31:36] <YaronK> ...and those, hopefully, wouldn't have XML definitions of their own. [17:37:23] <YaronK> TrevorParscal - here's another issue, separate from the MediaWiki ones: I thought of another possibility for the naming of the "app data" tags. [17:37:44] <YaronK> My idea was <settings> and <setting>, which I stuck in here: http://usability.wikimedia.org/wiki/Template_forms#Defining_the_interface_and_display [17:37:53] <YaronK> What do you think? [17:39:13] <TrevorParscal> well, is setting general enough? [17:39:23] <TrevorParscal> yes, people will use it however they like no matter what it's named [17:41:02] <TrevorParscal> but as a matter of naming, <data app="someapp"> is very generic (good thing imo) and the reuse of <field name="foo" value="bar" /> is really great [17:41:04] <YaronK> I would think it's general enough... and it makes conceptual sense to me, since it matches things like "LocalSettings.php". [17:41:49] <TrevorParscal> YaronK: I don't see how it's relevant to LocalSettings.php [17:42:15] <YaronK> I just mean, it's similar naming for a similar concept - the data relevant to specific tools/extensions. [17:42:25] <TrevorParscal> it's extra data, which may be generally useful to specific applications [17:42:51] <TrevorParscal> even if there were a similarity [17:43:07] <YaronK> It's application-specific data, which I think "setting" is really a synonym for. [17:43:20] <TrevorParscal> Template authors and Wiki System Administrators aren't going to be the same people in most cases, and you are basing this naming decision on your assumption of domain knowledge [17:44:11] <YaronK> No, I don't think you need to know about LocalSettings.php to understand the concept - I'm just saying it would be a nice synchronicity. [17:44:50] <TrevorParscal> well, I think we dissagree, so we should get other opinions involved as well [17:44:54] <YaronK> And the other nice thing about it, I think, is that it lends itself well to the singular, <setting>. [17:45:09] <YaronK> Alright... is anyone else following this conversation? :) [17:45:12] <TrevorParscal> but also causes yet another element name and type [17:45:55] <YaronK> Well, actually, what did you mean about reuse of <field>? Is that the name of the tag you wanted within <data>? And where else is it getting used? [17:46:12] <TrevorParscal> the concept behind using label and description tags as containers for msg tags is powerful - we should be seeking to use that model for other things [17:46:33] <TrevorParscal> yes, it's used in both type and data [17:46:46] <YaronK> Oh, by <field> you meant not literally the word "field". [17:46:50] <TrevorParscal> both of which may only contain any number of name valua pairs [17:47:10] <TrevorParscal> if you want to do <field name="foo">bar</field> that's cool too [17:47:19] <YaronK> Right, I totally agree. [17:48:00] <YaronK> Was that an argument against using <settings> and <setting>, or were you speaking tangentially? [17:48:37] <TrevorParscal> but <data><field />...</data> and <type><field />...</type> is great because we can use the same tags inside, easier to learn and simpler to process the data as well [17:49:19] <YaronK> Sure. [17:49:22] <TrevorParscal> you can have routines like "turn this element and it's children into an assciative array" or "turn this element and it's children into a single message given this preferred language" [17:49:38] <YaronK> Yeah. [17:49:42] <TrevorParscal> and it can be used on several elements that share the same structure [17:50:06] <TrevorParscal> I would support changing the value attribute to just using the text of the tag content [17:50:15] <TrevorParscal> aka - <field name="foo">bar</field> [17:50:55] <YaronK> Right, that was our consensus before, I thought. [17:51:13] <TrevorParscal> <!ELEMENT field CDATA> [17:51:14] <TrevorParscal> <!ATTLIST field name CDATA #REQUIRED> [17:51:26] <TrevorParscal> instead of... [17:51:27] <TrevorParscal> <!ELEMENT field EMPTY> [17:51:27] <TrevorParscal> <!ATTLIST field name CDATA #REQUIRED> [17:51:27] <TrevorParscal> <!ATTLIST field value CDATA #REQUIRED> [17:51:43] <YaronK> Okay, yeah. [17:51:56] <TrevorParscal> I can change the DTD if you want [17:52:33] <TrevorParscal> http://usability.wikimedia.org/wiki/Template_forms#Document_Type_Definition [17:52:35] <TrevorParscal> done [17:53:15] <YaronK> Wait, so "field" is an actual literal? [17:53:25] <TrevorParscal> yes [17:53:39] <YaronK> In the <data> tag? And if so, where else? [17:53:42] <TrevorParscal> just as msg is a literal [17:53:52] <YaronK> That one I know. [17:53:54] <TrevorParscal> in the type tag [17:54:01] <YaronK> Oh, okay. [17:54:07] <TrevorParscal> hence <!ELEMENT type (field)> [17:54:07] <TrevorParscal> <!ATTLIST type name CDATA #REQUIRED> [17:54:34] <YaronK> You could just as well replace "field" with "setting"... [17:54:52] <TrevorParscal> why would you do that? [17:55:11] <TrevorParscal> it's just making things more complex for both the template author and the programmer using the data [17:55:24] <TrevorParscal> keep it simple ... [17:55:27] <YaronK> Well, I see a few problems with "field" - it's possibly too generic, in that there's already the concept of form fields, and XML fields. [17:55:40] <YaronK> Neither of which this would be. [17:56:14] <YaronK> To clarify, I'm saying replace "field" with "setting" in the DTD. [17:56:30] <TrevorParscal> i think you are trying to hard to name things in a way that communicates everything you would ever need to know about the format [17:56:38] <TrevorParscal> what does a <td> tag do/mean? [17:56:56] <TrevorParscal> yet, we seem to have no trouble with that [17:56:57] <YaronK> Well, if I had to name that, I might come up with something different. [17:57:02] <TrevorParscal> i wouldn't [17:57:09] <TrevorParscal> what would you name it? [17:57:18] <TrevorParscal> it's hard to beat the brevity of that tag [17:57:45] <YaronK> Okay, fine - at the very least, <td> doesn't lead to the confusion of possibly meaning something else. [17:58:08] <TrevorParscal> and in the end, it's not about things being named perfectly - it's important they are named generally enough that extending in the future doesn't cause the naming to become silly and misleading though [17:58:27] <TrevorParscal> the <b> tag did though, and it got changed to <strong> [17:58:37] <TrevorParscal> the pendulum can totally swing too far in the other direction [17:58:49] <TrevorParscal> it's just a matter of balance [17:59:11] <YaronK> Well, that's why I like <setting> and <settings> - I think it perfectly describes the data. [17:59:35] <TrevorParscal> only if it's being used by someone who thinks of the data as a setting [18:00:20] <YaronK> Well, is there an example of data that wouldn't be used as a setting? [18:00:29] <TrevorParscal> $('body').data() is a better design than $('body').settings() [18:00:49] <TrevorParscal> because settings is very specific, and possibly misleading [18:01:36] <RoanKattouw> nkomura: Yeah I'm here now, my connection dropped earlier [18:01:55] <nkomura> hey [18:01:57] <RoanKattouw> YaronK: No! Do NOT rely on $wgTitle in the parser, use $parser->getTitle() instead [18:02:03] <TrevorParscal> similarly, in this case, we are storing generic data places which is generally ignored by the use of the information, not changing settings to the general object [18:02:22] <nkomura> RoanKattouw: it is time for config change for en.wikinews [18:02:26] RoanKattouw has been on a crusade against $wgTitle in unnecessary places for over a year now [18:02:28] <RoanKattouw> Aye [18:02:29] <YaronK> RoanKattouw - okay. Though the problem is that $parser->getTitle() doesn't indicate whether there was transclusion or not. [18:02:30] <RoanKattouw> Let's do it [18:02:32] <nkomura> i wanted to test a few things [18:02:37] <nkomura> first [18:02:37] <YaronK> Neither does $wgTitle, of course. [18:02:40] <TrevorParscal> RoanKattouw: we were looking to compare $wgTitle with $parser->getTitle() to detect transclusion, but if you have a better way - that would be awesome [18:03:02] <RoanKattouw> I don't know, ask Tim or look at the parser docs; I'll look it up later [18:03:10] <YaronK> TrevorParscal - is there an example where "settings" could be misleading? [18:03:18] <RoanKattouw> nkomura: What do you want to test and where? [18:03:25] <YaronK> (example of where) [18:04:13] <nkomura> i wanted to test to make sure the settings for the enhanced toolbar changes from old -> the enhanced [18:20:08] <TrevorParscal> YaronK: i've tweaked this proposal a bit [18:20:09] <TrevorParscal> http://usability.wikimedia.org/wiki/Talk:Template_forms#Another_proposal [18:20:42] <YaronK> Okay. [18:20:49] <TrevorParscal> that format is something I would consider complete. If you have specific issues with that format, let me know - but I would really like to just get started using that one [18:20:56] <YaronK> The <label> and <description> for groups definitely makes sense. [18:21:11] <YaronK> Well, I still prefer <settings> and <setting>, I think. [18:21:16] <TrevorParscal> I would not [18:22:02] <YaronK> Well, that might be the last issue, as far as the format. [18:22:29] <TrevorParscal> brion: are you available for consultation? [18:22:49] <brion> i'm poking at other things but feelf ree to ask, i'll see what i can do [18:23:16] <TrevorParscal> well - it's a rather silly and overly complex issue, so I won't bother you with it - thanks though :) [18:23:31] <YaronK> Time to ask mediawiki-l again? :) [18:23:42] <TrevorParscal> oh gosh please no [18:23:54] <RoanKattouw> Why mediawiki-l guys? [18:23:57] <RoanKattouw> That's a support list [18:23:59] <RoanKattouw> Use wikitech-l [18:24:00] <TrevorParscal> all you will get is a bunch of people saying why wikitext should be abandoned [18:24:12] <YaronK> Oh yeah, I meant wikitech-l. [18:24:18] <TrevorParscal> RoanKattouw: also good point, but I assumed he meant wikitech-l [18:24:43] <YaronK> But on a serious note, Nimish and Michael might be good people to ask. [18:24:53] <YaronK> Hopefully they won't split, one in each direction. [18:25:10] <nimish_g> yes? Let me scroll up some [18:25:13] <TrevorParscal> michael is unfourtunately out of the office handling family things [18:25:17] <YaronK> Alright. [18:25:19] TrevorParscal hands the floor to nimish [18:25:48] <YaronK> Well, it doesn't have to be settled right away - I actually have the Template Info extension mostly working already, with a slightly older version of the DTD. [18:25:59] <nimish_g> so the issue is naming it "data" vs "settings" and "field" vs "setting"? [18:26:07] <YaronK> Yeah, that's it. [18:26:39] <thedj> nkomura: i've been getting some vibes in the village pumps, that people don't really know wether or not their feedback is being heard. It might be an idea to sign the feedback page when you guys have read it. [18:26:43] <nimish_g> and this is for the part that lets users put in whatever they want? [18:27:04] <YaronK> Yeah, for app-specific data and/or settings. :) [18:27:30] <TrevorParscal> using data/field better accomplishes these goals: brevity, reuse, extendablility [18:28:09] <YaronK> I prefer settings/setting for clarity and, to some extent, consistency. [18:28:30] <nkomura> thedj: that's a good idea [18:28:42] <nimish_g> hm, I don't like 'setting' b/c that implies to me that changing this would change core functionality of whatever it is I'm editing [18:28:49] <nkomura> thedj: i need to check the config change for en.wikinews [18:28:58] <nkomura> so one momnet [18:32:22] <nimish_g> maybe something like extensionData and field might make it more clear [18:32:35] <nimish_g> but with 1 word instead of "extensiondata" b/c everything else is 1 word [18:32:51] <TrevorParscal> and hopefully not as many characters as that [18:33:01] <TrevorParscal> <bucket> :) [18:33:24] <YaronK> One other idea that was brought up before was <appdata>. [18:33:37] <YaronK> <appdata app="..."> might look weird, but maybe not that weird. [18:37:27] <nimish_g> yeah, does look weird but I definitely like the name, it makes it clear that "hey, if you mess with this info, this app breaks, but nothing else does" [18:37:51] <nimish_g> whereas settings or data isn't so clear about that, even with the "app =" field [18:38:27] <nkomura> folks, i'm happy to announce that en.wikinews made the usability beta default [18:38:57] <nimish_g> YAY!! [18:39:00] <RoanKattouw> TrevorParscal: With pain in my heart I'm gonna take your beautiful daughter out of the channel topic [18:40:30] <TrevorParscal> <app name="joes-bot"><field name="foo">bar</field>...</app> [18:41:44] <YaronK> Yeah, that works for me, I think. [18:42:54] <TrevorParscal> let's go with that [18:46:35] <YaronK> Alright, I'll change the doc, and we'll see how we feel about it later, I guess. [18:47:09] <YaronK> Speaking of naming, one other kind of minor issue: should the name of the new MW extension be "TemplateInfo" or "Template Info"? [18:47:28] <YaronK> I always go with a space, but "UsabilityInitiative" has none. [18:48:07] <RoanKattouw_away> Don't put spaces in extension names, please [18:48:23] <YaronK> Why is that? [18:49:55] <nkomura> thedj: I'm back [18:50:06] <thedj> nkomura: :D [18:50:39] <nkomura> will you send me the thread in the VP where the concern is raised [18:50:57] <thedj> oh, it's been said a couple of times. [18:51:03] <nkomura> we haven't been great replying to the feedback, but we do read them and apply the changed [18:51:18] <RoanKattouw_away> YaronK: People on UNIX/Linux systems will have to cd to that directory [18:51:24] <thedj> yeah, i think it's important to show people that you guys actually DO read it. [18:51:26] <nkomura> you know the changes is coming right? [18:51:39] <RoanKattouw_away> cd Templ[TAB] --> cd Template --> gah now I gotta type backslash space before it autocompletes [18:51:40] <thedj> i think they understand you can't answer everyone individually. [18:51:59] <nkomura> so just signing for reading it? [18:52:19] <RoanKattouw_away> Plus spaces are uncommon in extension names as far as I've seen [18:52:30] <nkomura> for the feedback we take actions, i try to add ref to bugzilla and so forth [18:52:43] <thedj> yeah i think that at least will give people the idea that the page is being read regurly. [18:53:02] <nkomura> yeah [18:55:00] <nkomura> i'll do that and also ask the team to reply [18:55:16] <thedj> perhaps a blog post some time, specifically about the feedback and how it is handled is an idea as well. [18:55:34] <YaronK> RoanKattouw_away - certainly the directories for extensions never contain spaces, but the extension names themselves seem to, about half the time. [18:56:14] <nkomura> thedj: do you recall which pages the folks were referring to? [18:56:21] <TrevorParscal> no spaces in extension names plz [18:56:45] <TrevorParscal> Yaron: when in doubt, please follow precedence [18:57:00] <thedj> nkomura: feedback talk page and the suggestions pages of the Acai/Babaco pages i believe [18:57:08] <nkomura> k [18:57:15] <nkomura> will focus on that first [18:57:17] <TrevorParscal> YaronK: please do not introduce noise in the system [18:57:21] <thedj> nkomura: on the other hand, i doubt many of the users follow up themselves, so it might be more their perception than reality. [18:57:30] <thedj> but never hurts to reassure. [18:57:36] <YaronK> TrevorParscal - what do you mean by precedence, and noise? [18:57:47] <nkomura> discussion page on main page seems active with replies [18:57:56] <nkomura> thedj: thanx [18:58:25] <thedj> nkomura: no problem [18:58:56] <TrevorParscal> YaronK: the extensions directory has many extensions in it, more than 90% use a consistent naming scheme TitleCaseWithNoSpaces - that would constitute a precedence [18:59:38] <YaronK> Right - the directory names never have spaces, but extension names themselves sometimes do. [18:59:44] <TrevorParscal> YaronK: following anything other than said precedence would cause noise - aka irregularity scattered throughout conformity [19:00:01] <YaronK> See here, for example: http://en.wikipedia.org/wiki/Special:Version [19:00:18] <YaronK> A fair number of extensions have spaces in their names, including extensions created by Brion and Nimish. [19:00:41] <TrevorParscal> that's not true [19:01:02] <TrevorParscal> User Daily Contributions is an internationalized message, the name of the extension is UserDailyContribs [19:01:31] <TrevorParscal> Central Auth - again, the extension name is actually CentralAuth [19:01:51] <YaronK> How do you define the extension name, then? [19:02:45] <TrevorParscal> and once again - even if that were true, you are saying that 3 out of 55 use convention A, all else use convention B [19:03:06] <YaronK> Well, what I'm saying is, maybe it's not a convention either way. [19:03:10] <YaronK> I don't know the answer. [19:03:16] <TrevorParscal> It is, that's the answer [19:03:42] <TrevorParscal> you can specify the text for the version page in the credits array [19:03:56] <YaronK> Yes, I know; but what dictates the extension name? [19:03:58] <TrevorParscal> but the extension name should be TitleCaseWIthNoSpaces [19:04:03] <TrevorParscal> the name of the folder [19:04:16] <YaronK> I wouldn't say that. [19:04:18] <TrevorParscal> why is this so hard for you to accept? [19:04:23] <YaronK> Wow. [19:04:30] <nkomura_break> YaronK and TrevorParscal, can you guys time-out? [19:04:43] <TrevorParscal> ? [19:04:50] <TrevorParscal> sure [19:05:21] <nkomura_break> i think discussing naming convention over IRC is not productive [19:05:32] <nkomura_break> especially both are not ready to compromise [19:05:48] <nkomura_break> i wish brion is here [19:06:36] <nkomura_break> YaronK: will you propose your naming convention for the extension you are building via email to usability alias? [19:07:08] <nkomura_break> we can discuss is at our next call on tuesday [19:07:17] TrevorParscal goes to lunch [19:07:29] <YaronK> I just wanted to know which name to go with - I could go either way. I guess it's "TemplateInfo", then. [19:07:52] <YaronK> And I'll stick to spaces for my own extensions, unless I see some documentation otherwise. :) [19:08:50] <nkomura_break> if you are ok with that, that will simplify things [19:08:55] <nkomura_break> and saves time [19:09:02] <nkomura_break> thanx! [19:10:34] <RoanKattouw_away> YaronK, TrevorEating: The name of the extension in Special:Version is not very relevant, it's the name of the extension folder and the .php file that counts [19:11:53] <YaronK> RoanKattouw - well, they're relevant for different things. [19:12:41] <YaronK> For instance, in about a week we're going to have a "Semantic MediaWiki Camp" in Germany - it's a conference/meeting named after an extension, which has a space in its name. [19:15:11] <YaronK> TrevorEating - oh, sorry, when you wrote "the name of the folder", I thought you meant that as an answer to my question, "what dictates the extension name?" [19:15:51] <YaronK> Which is what I disagreed with. [19:16:07] <YaronK> I think it was a misunderstanding brought on by the fragmented sentences of IRC. [19:17:57] <RoanKattouw> I couldn't care less about the name of the extension in Special:Version, as long as the directory name is spaceless [19:19:49] <YaronK> Alright, well, no argument from me there. [19:20:20] <YaronK> I'd say what really determines the extension name, actually, is the name of the documentation page on mediawiki.org. [19:21:13] <RoanKattouw> YaronK: As for testing whether you're being transcluded: a tag hook has a $frame parameter, compare $parser->getTitle() with $frame->title [19:24:07] <YaronK> Okay - which parameter is $frame? I see three params - "$input, $args, $parser". [19:24:18] <RoanKattouw> The fourth [19:24:34] <RoanKattouw> http://www.mediawiki.org/wiki/Manual:Tag_extensions#Example [19:26:44] <YaronK> Oh, I see - it's the difference between a tag and a "function tag"? [19:27:15] <YaronK> What's the difference between the two - does it just depend on which version of MW one is using? [19:27:23] <RoanKattouw> Tag = <foo> [19:27:26] <RoanKattouw> Function = {{#foo:}} [19:27:32] <RoanKattouw> They have different places in the parsing order [19:27:59] <YaronK> Well, it seems to me, looking at the parser code, that there are tags, functions, and "function tags". [19:28:15] <RoanKattouw> Oh yeah that's something new that vvv introduced [19:28:25] <RoanKattouw> In fact, it's probably just what we need [19:28:30] <RoanKattouw> As its contents don't get preprocessed [19:29:18] <vvv> hi [19:29:33] <YaronK> Ah, that's quite useful. [19:30:23] <vvv> Function tag is a tag parsed at preprocessor stage [19:30:42] <vvv> I intended to use then in not-yet-commited InlineScripts extension [19:31:04] <YaronK> Interesting. [19:31:13] <RoanKattouw> vvv: What's the syntax look like? [19:31:56] <vvv> <wikiscript>a = 2; b = 3; out("{{number|" + a + "|" + b + "}}");</wikiscript> [19:32:28] <YaronK> Is the documentation, that Roan linked to before, correct? It has a "$frame" parameter, which I think only "function tags" have, but it's called with setHook() instead of setFunctionTagHook(). [19:32:44] <YaronK> The URL is http://www.mediawiki.org/wiki/Manual:Tag_extensions#Example . [19:32:53] <RoanKattouw> YaronK: No, tag hooks also have a $frame param [19:33:28] <vvv> To be honest, it wasn't used before, so I'm not sure it always work correctly [19:34:07] <vvv> public static function scriptHook( &$parser, $frame, $code, $attribs ) { [19:34:12] <vvv> That's the working example [19:35:27] <YaronK> Ah, okay - it looks like that $frame param was added sometime recently, like in MW 1.16. [19:36:12] <YaronK> I need to update MW on the wiki I'm using for development. [19:37:29] <vvv> YaronK: function hooks itself were added circa August [19:37:54] <YaronK> Okay, good to know, thanks. [19:37:57] <RoanKattouw> That's no problem for us, most of our code needs 1.16 anyway [20:32:12] thedj pondering creating a fancybox plugin for wikipedia [20:32:13] <thedj> http://fancybox.net/example [20:32:51] <thedj> add caption to the bottom + description and "embed" link, and you have something very cool i think... [20:38:44] <thedj> nkomura: has there been interest in such functionality among the readers ? to "zoom" into an image ? [20:41:21] <Ryan_Lane> prototype VM is essentially out of space... [20:41:28] <Ryan_Lane> I can't make any new wikis [20:41:48] <Ryan_Lane> ... / is at 99% [20:46:17] <nkomura> Ryan_Lane: will you leave email message to rob? [20:46:29] <nkomura> he can purchase additional space for us [20:46:39] <nkomura> thedj: i'm looking at the page you sent me [20:47:00] <nkomura> so is the caption editable? [20:47:17] <thedj> no, but we can make that of course. [20:47:40] <nkomura> really neat [20:48:00] <thedj> and have a "file description" link/button and an "embed/download this image" button. [20:48:40] <nkomura> are you thinking of this feature within wikipedia articles or for Commons [20:48:41] <nkomura> ? [20:48:49] <thedj> wikipedia articles. [20:49:35] <thedj> the idea is that you would get a better look at a thumb, without leaving the page. [20:50:03] <nkomura> from our study and feedback, we haven't heard much interest in such feature [20:50:19] <thedj> k, just wondering. [20:50:20] <nkomura> but our focus has been for editing experience for new users [20:50:41] <nkomura> have you tried mdale's add-media-wizard? [20:50:48] <thedj> yes. [20:51:05] <nkomura> so in his process, he allows caption editing nicely [20:51:21] <nkomura> so we are trying to integrate his work into image icon in the new toolbar [20:51:38] <nkomura> AMW is working as gadget already, as you must know [20:52:14] <thedj> yeah, this would be focused more on the readers, and less on the starting editors I guess. [20:52:31] <nkomura> yeah [20:53:01] <thedj> i'll play around a bit with it this weekend, see what i can come up with. [20:53:50] <nkomura> :) [21:16:41] RoanKattouw_away removes some crap from his home dir, now at 97% :) [21:18:20] <nkomura> RoanKattouw_away: how about the videos from Wikimania? [21:18:28] <nkomura> are they still on prototype? [21:19:09] <nkomura> Ryan_Lane: we used prototype to host Wikimania video temporarily [21:21:01] <RoanKattouw_away> Good one [21:21:21] <RoanKattouw_away> Hah that's 3 GB right there [21:21:56] <RoanKattouw_away> catrope@prototype:/home/streams$ df -h [21:21:58] <RoanKattouw_away> Filesystem Size Used Avail Use% Mounted on [21:22:00] <RoanKattouw_away> /dev/xvda 12G 8.3G 3.3G 72% / [21:22:01] <RoanKattouw_away> Whee [21:22:09] RoanKattouw_away goes away again [21:22:09] <nkomura> yipeee!