W3C home > Mailing lists > Public > public-webplatform@w3.org > November 2013

Re: Second JS bulk upload

From: Renoir Boulanger <renoir@w3.org>
Date: Mon, 25 Nov 2013 13:01:38 -0500
Cc: Max Polk <maxpolk@gmail.com>, Ryan Lane <rlane32@gmail.com>
Message-Id: <D11DDDC3-6F3A-4FAD-A805-39D1A2329D46@w3.org>
To: Webplatform List <public-webplatform@w3.org>
Hey all

I have been looking around the import and seen notes asking to delete pages [0].

It turns out MediaWiki doesn't allow delete pages and sub pages in an automated process. It means that we would have to run it via the database.

After some discussion between me and Ryan on how to delete pages under a parent, running queries against the database is not the best thing to do. 

We might have to either do it manually, or create some sort of bot that would take care of the task.

  [0]: http://docs.webplatform.org/test/javascript


> On 11/24/13 3:48 PM, Max Polk wrote:
>> In a dictionary or encyclopedia, everything is at the same top-level
>> namespace.  In a wiki, in some rare cases subpages can be useful, but to
>> categorize in Mediawiki, the main approach is to "tag" the page with a
>> Category:Something inside double square brackets.  You can add multiple
>> categories.
>> To diverge from the built-in power of Mediawiki categorization by trying
>> to replace it with subpages is a mistake.  Just click "random page" over
>> and over again on Wikipedia and see how many subpages you run into
>> (almost never).
>> We already have several top-level subdivisions of webplatform docs, one
>> of them being the /javascript/ page path.  Let's not use additional
>> paths when all we need to do is "tag" pages (with a category).  There is
>> even a facility to list all pages in a category automatically, and you
>> can even edit that page.  For example, see this:
>> http://en.wikipedia.org/wiki/Category:Algebra
>> It is a category page, with autogenerated page inclusion.  Just "tag" a
>> page with "[[Category:Algebra]]" and it appears in the category page.
>> But you can also introduce the category by editing the category page
>> itself (the material on the top).
>> Trying to use subpaths under /javascript/ in this wiki feels to me like
>> a lack of harmony, awkward, and a divergence from the best strengths
>> Mediawiki has to offer, especially since the power of "tagging" pages
>> (categorization) has been completely missing, from all our conversations.
>> Best approach is to try to tag (categorize) pages first, then, and only
>> then if that fails, fall back to additional subpage paths.  P.S. it
>> won't fail.  ;-)
>> On Sun, Nov 24, 2013 at 2:23 AM, PhistucK <phistuck@gmail.com
>> <mailto:phistuck@gmail.com>> wrote:
>>    It seems a bit messy, to have the API and the language reference
>>    (syntax, statements, operators) in the same level...
>>    For example -
>>    javascript/String
>>    javascript/Statements
>>    Also, if we keep them (and I think we should), any non API path
>>    component ("Statements", "Operators") should be lower case.
>>    ☆*PhistucK*
>>    On Sun, Nov 24, 2013 at 6:01 AM, Max Polk <maxpolk@gmail.com
>>    <mailto:maxpolk@gmail.com>> wrote:
>>        The next round of JavaScript pages have just been uploaded.
>>          Root path:
>>        http://docs.webplatform.org/__test/javascript
>>        <http://docs.webplatform.org/test/javascript>
>>        The links now work, it should be navigable at this point.  Note
>>        that this page, in the original, was intended to the landing
>>        page, which pointed to the below top-level pages:
>>        http://docs.webplatform.org/__test/javascript/JavaScript___Reference
>>        <http://docs.webplatform.org/test/javascript/JavaScript_Reference>
>>        Then these top-level pages, in the original, were helpers to
>>        point you to the other pages:
>>        http://docs.webplatform.org/__test/javascript/Functions
>>        <http://docs.webplatform.org/test/javascript/Functions>
>>        http://docs.webplatform.org/__test/javascript/Statements
>>        <http://docs.webplatform.org/test/javascript/Statements>
>>        http://docs.webplatform.org/__test/javascript/Operators
>>        <http://docs.webplatform.org/test/javascript/Operators>
>>        http://docs.webplatform.org/__test/javascript/Objects
>>        <http://docs.webplatform.org/test/javascript/Objects>
>>        http://docs.webplatform.org/__test/javascript/Properties
>>        <http://docs.webplatform.org/test/javascript/Properties>
>>        Why are those there?
>>        Because we took original html files that were arranged very
>>        tree-like in their URL path structure, and began *flattening* to
>>        be more like what an encyclopedic venue such as a wiki is good
>>        at storing and finding.  By flattening I mean taking out the
>>        "Objects/" path prefix to many pages, and things like that.
>>          While we still use subpages, we don't technically need that
>>        landing page or the subtopic pages just so everything can be
>>        found.  A wiki you simply search for things.  Having said that
>>        these pages still look useful to me, although they will probably
>>        be reworked.
>>        We are messaging the pages to be more like a wiki where URLs are
>>        very important, and less like a tech site whose URLs don't
>>        always have to make sense.  We want the URLs to be clean.
>>          Fortunately for us, they were already very clean and well
>>        organized to begin with.  That definitely is making our
>>        flattening effort a lot easier.  Three cheers to organization
>>        the pages donator Microsoft imposed, and the good content!
>>        The work below is still outstanding:
>>            Automation to do:
>>            2. talk about static method page name (X/X.method versus
>>            X/method)
>>            3. talk about Global/* (nobody says
>>            "Global.decodeURIComponent" so maybe hide the Global prefix)
>>            Non-automation to do:
>>            1. Discuss keeping Object/constructor and erase six other
>>            pages (Array/constructor, Boolean/constructor, etc), that
>>            are essentially duplicates.
>>            2. Discuss keeping Object/prototype and erase six other
>>            pages (Array/prototype, Boolean/prototype, etc), likewise.
>>            3. Probably should not erase six other pages for valueOf:
>>            (Array/valueOf , Boolean/valueOf , etc), likewise, since
>>            they are each custom versions that return different things
>>            (a string, an array, a boolean value, etc).
>>            4. Create String/X pages for each of the String HTML Tag
>>            Methods (string.anchor, string.big, string.blink, etc)
>>            5. Discuss folding arguments/0 n Properties and RegExp/1 9
>>            Propertiesinto their main page then delete them
Received on Monday, 25 November 2013 18:01:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:56 UTC