User talk:Nickolay

  • Revision slug: User_talk:Nickolay
  • Revision title: User talk:Nickolay
  • Revision id: 125196
  • Created:
  • Creator: Nickolay
  • Is current revision? No
  • Comment /* Creating toolbar buttons */ re

Revision Content

I thought that it was better than nothing, and someone can overwrite it anytime they've got something better. --Briprowe 18:07, 29 Jul 2005 (EST)

Deletion Requests

Re: your not on User_talk:Callek

I agree that simply no links is not enough, my opinion has been shaped somewhat since then. Feel free to drop any of the requested deletions off that page if you have a feeling they should stay.

I'll Create a (temporary) page Somewhere later on, (where I'm not too sure); to list all Redirects that are intended to stay, and why (if not blatantly obvious). In the future, this can be replaced by using Category links on each redirect page to categorize "why it is staying", but that needs to wait until Redirects are categorizeable.

--Callek 21:59, 3 Aug 2005 (PDT)

XSLT reference

I guess I don't know how to do a simple redirect. I deleted the content of my pages and added a link to the new pages. There are no longer any links to my pages anyway.

Thanks for the heads up about the new XSLT reference. I didn't know it was there. It appears that XSLT:Elements and XPath:Axes are filled in with up-to-date content on every page.

XPath:Functions appears to be full of blank pages. I guess that's where I'll start filling things in. If there's anything else I can focus on in the XSLT/XPath section, I'd be glad. Jonnyq

Re: Redirect Categories (from User_talk:Callek) I agree it may not be maintained well enough, but what I do hope to acheive is a de-facto standard here about "what do we do about redirects". I intend to propose a MW change to polvi/shaver/dria et-all which will put an "Should This Redirect Stay" category on all page moves, (not self-created redirects however). This will help to "keep up with" it all, I will also poke Polvi to run a SQL query to find all pages which are redirects for me, so I can categorize them as either "needs to be deleted" or "needs to stay" or "I am not sure". This is to help keep devmo clutter down, especially as we develop rules for these things. The document one, was simply a quick and dirty test of what I am thinking of doing. Not-so-much a "final thing". I would still need to create a Category: information, and other things. And this would bake on the mailing list before I went "all out" on categorizing it. Worst case I would do is a manually updated page in my User (or Devmo) area saying which ones are meant to stay. --Callek 10:38, 26 Aug 2005 (PDT)

Re: User_talk:Callek#External_redirects

I do not feel strongly about it in this case, though I do feel strongly about ones which have any semblance of being migrated instead. (Such as the "Priority Items for Migration" external redirects on the existing content page. --Callek 11:27, 21 September 2005 (PDT)

Based on re-reading your comments (and dria's posted today) at Help_talk:External_Redirects I'll concede this point, and possibly consider writing up a Special: page to enumerate all "real" external Links used, (and allow searching of them) this would need to be discussed with dria and company first, and of course be after my creation of Special:Redirects. --Callek
My biggest desire for this was to NOT have recursive redirects abound, (link TO mozilla.org Then have a mozilla.org page redirect to a page HERE, and then possibly have THAT page redirect to its "resting" location HERE) just seems like alot of extra work to me --Callek 23:15, 21 September 2005 (PDT)

Thanks

Thanks for the telling me about the Help:Contents section for Help:Wiki_Markup_Reference info. I guess I'm blind. I went ahead and removed it from the Preferences System discussion since it's not really related. --S280Z28

Re: document.loadOverlay

I also prefer DOM prefix for this, when we have the common setup it "just makes sense" to me to use it, we can keep redirects to allow "accidental linking" but imho, all links to redirects should be periodically changed to links to the actual article. I await Waldo's reply --Callek 08:36, 11 December 2005 (PST)

The point of the change was to eliminate a redirect that will have to happen every time that link's clicked, which will increase the time it takes for that link to load. In order for MDC to be most useful it has to be snappy, and a redirect is not going to be snappy. As for prefixed vs. unprefixed editability, is one really that much easier than the other in the long run? Creating the link is a one-time process, but links will be used hundreds of times. It may take (generously) an extra half-minute to use the long form, but that half-minute will easily be eaten up as more and more users click the link. This site is for the user, not for the editor, and when it comes to link forms I think user needs outweigh editor needs. But anyway, having a guideline for this makes some sense. I wouldn't prioritize it too much, tho, because it's nothing MDC users will actually see, and lack of content is a much more important problem than slightly varying link styles.--Waldo 14:02, 11 December 2005 (PST)

Creating toolbar buttons

Re: this; To me, the <div class="note"> makes sense here, while to me your change is not "wrong" it is not as clear/apparant to someone finding that article and wants to do it without knowing the needed material. I'll leave the final call on what version to use up to you though. --Callek 21:38, 30 January 2006 (PST)

Nickolay's version (without the "note" div) is more appropriate I think. As the second paragraph of the introduction it makes perfect sense as part of the regular text of the article. -- dria 06:13, 31 January 2006 (PST)
Yes, that was exactly my thinking. For me, class="note" is for drawing reader's attention to something important that could be missed without the special formatting (for example for a note between long text paragraphs). In this case, it's the second paragraph, which is separated from the rest of article with a TOC div. Pretty easy to notice. Also the note div and the TOC div didn't look good together (at least for me).
BTW, you can comment on the ordinary talk pages, there's a pretty high chance I'll notice it. --Nickolay 16:45, 31 January 2006 (PST)

Revision Source

<p>I thought that it was better than nothing, and someone can overwrite it anytime they've got something better.
--Briprowe 18:07, 29 Jul 2005 (EST)
</p>
<h3 name="Deletion_Requests"> <a href="en/Deletion_Requests">Deletion Requests</a> </h3>
<p>Re: your not on <a href="User_talk:Callek">User_talk:Callek</a>
</p><p>I agree that simply no links is not <i>enough</i>, my opinion has been shaped somewhat since then.  Feel free to drop any of the requested deletions off that page if you have a feeling they should stay.
</p><p>I'll Create a (temporary) page Somewhere later on, (where I'm not too sure); to list all Redirects that are intended to stay, and why (if not blatantly obvious).  In the future, this can be replaced by using <a href="Special:Tags?tag=All_Categories&amp;language=en">Category</a> links on each redirect page to categorize "why it is staying", but that needs to wait until Redirects are categorizeable.
</p><p>--<a href="User:Callek">Callek</a> 21:59, 3 Aug 2005 (PDT)
</p>
<h3 name="XSLT_reference"> XSLT reference </h3>
<p>I guess I don't know how to do a simple redirect.  I deleted the content of my pages and added a link to the new pages.  There are no longer any links to my pages anyway.
</p><p>Thanks for the heads up about the new XSLT reference.  I didn't know it was there.  It appears that <a href="en/XSLT/Elements">XSLT:Elements</a> and <a href="en/XPath/Axes">XPath:Axes</a> are filled in with up-to-date content on every page.
</p><p><a href="en/XPath/Functions">XPath:Functions</a> appears to be full of blank pages.  I guess that's where I'll start filling things in.  If there's anything else I can focus on in the XSLT/XPath section, I'd be glad. <a href="User:Jonnyq">Jonnyq</a>
</p><p>Re: Redirect Categories (from <a href="User_talk:Callek">User_talk:Callek</a>)
I agree it may not be maintained well enough, but what I do hope to acheive is a de-facto standard here about "what do we do about redirects".  I intend to propose a MW change to polvi/shaver/dria et-all which will put an "Should This Redirect Stay" category on all page moves, (not self-created redirects however).  This will help to "keep up with" it all, I will also poke Polvi to run a SQL query to find all pages which are redirects for me, so I can categorize them as either "needs to be deleted" or "needs to stay" or "I am not sure". This is to help keep devmo clutter down, especially as we develop rules for these things.
The document one, was simply a quick and dirty test of what I am thinking of doing.  Not-so-much a "final thing".  I would still need to create a Category: information, and other things.  And this would bake on the mailing list before I went "all out" on categorizing it.  Worst case I would do is a manually updated page in my User (or Devmo) area saying which ones are meant to stay. --<a href="User:Callek">Callek</a> 10:38, 26 Aug 2005 (PDT)
</p>
<h3 name="Re:_User_talk:Callek.23External_redirects"> Re: <a href="User_talk:Callek#External_redirects">User_talk:Callek#External_redirects</a> </h3>
<p>I do not feel strongly about it in this case, <b>though</b> I do feel strongly about ones which have any semblance of being migrated instead.  (Such as the "Priority Items for Migration" external redirects on the <a href="Project:en/Existing_Content">existing content</a> page. --<a href="User:Callek">Callek</a> 11:27, 21 September 2005 (PDT)
</p>
<dl><dd> Based on re-reading your comments (and dria's posted today) at <a href="Help_talk:en/External_Redirects">Help_talk:External_Redirects</a> I'll concede this point, and possibly consider writing up a Special: page to enumerate <b>all</b> "real" external Links used, (and allow searching of them) this would need to be discussed with dria and company first, and of course be after my creation of Special:Redirects. --<a href="User:Callek">Callek</a>
</dd><dd> My biggest desire for this was to NOT have recursive redirects abound, (link TO mozilla.org Then have a mozilla.org page redirect to a page HERE, and then possibly have THAT page redirect to its "resting" location HERE)  just seems like alot of extra work to me --<a href="User:Callek">Callek</a> 23:15, 21 September 2005 (PDT)
</dd></dl>
<h3 name="Thanks"> Thanks </h3>
<p>Thanks for the telling me about the <a href="Help:en/Contents">Help:Contents</a> section for <a href="Help:en/Wiki_Markup_Reference">Help:Wiki_Markup_Reference</a> info. I guess I'm blind. I went ahead and removed it from the <a href="en/Preferences_System">Preferences System</a> discussion since it's not really related. --<a href="User:S280Z28">S280Z28</a>
</p>
<h3 name="Re:_document.loadOverlay"> Re: document.loadOverlay </h3>
<p>I also prefer DOM prefix for this, when we have the common setup it "just makes sense" to me to use it, we can keep redirects to allow "accidental linking" but imho, all links to redirects should be periodically changed to links to the actual article. I await Waldo's reply --<a href="User:Callek">Callek</a> 08:36, 11 December 2005 (PST)
</p><p>The point of the change was to eliminate a redirect that will have to happen every time that link's clicked, which will increase the time it takes for that link to load.  In order for MDC to be most useful it has to be snappy, and a redirect is not going to be snappy.
As for prefixed vs. unprefixed editability, is one really that much easier than the other in the long run?  Creating the link is a one-time process, but links will be used hundreds of times.  It may take (generously) an extra half-minute to use the long form, but that half-minute will easily be eaten up as more and more users click the link.  This site is for the user, not for the editor, and when it comes to link forms I think user needs outweigh editor needs.  But anyway, having a guideline for this makes some sense.  I wouldn't prioritize it too much, tho, because it's nothing MDC users will actually see, and lack of content is a much more important problem than slightly varying link styles.--<a href="User:Waldo">Waldo</a> 14:02, 11 December 2005 (PST)
</p>
<h3 name="Creating_toolbar_buttons"> Creating toolbar buttons </h3>
<p>Re: <a class="external" href="http://developer.mozilla.org/en/docs/index.php?title=Creating_toolbar_buttons&amp;curid=3996&amp;diff=24110&amp;oldid=24102">this</a>; To me, the <span class="plain">&lt;div class="note"&gt;</span> makes sense here, while to me your change is not "wrong" it is not as clear/apparant to someone finding that article and wants to do it <u>without</u> knowing the needed material.  I'll leave the final call on what version to use up to you though. --<a href="User:Callek">Callek</a> 21:38, 30 January 2006 (PST)
</p>
<dl><dd> Nickolay's version (without the "note" div) is more appropriate I think.  As the second paragraph of the introduction it makes perfect sense as part of the regular text of the article. -- <a href="User:Dria">dria</a> 06:13, 31 January 2006 (PST)
</dd></dl>
<dl><dd><dl><dd> Yes, that was exactly my thinking. For me, <code>class="note"</code> is for drawing reader's attention to something important that could be missed without the special formatting (for example for a note between long text paragraphs). In this case, it's the second paragraph, which is separated from the rest of article with a TOC div. Pretty easy to notice. Also the note div and the TOC div didn't look good together (at least for me).
</dd><dd> BTW, you can comment on the ordinary talk pages, there's a pretty high chance I'll notice it. --<a href="User:Nickolay">Nickolay</a> 16:45, 31 January 2006 (PST)
</dd></dl>
</dd></dl>
Revert to this revision