Re: Second JS bulk upload

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> wrote:

> The next round of JavaScript pages have just been uploaded.  Root path:
>
>     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
>
> 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/Statements
>     http://docs.webplatform.org/test/javascript/Operators
>     http://docs.webplatform.org/test/javascript/Objects
>     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
>>
>
>
>