Re: Attribution to MSDN on JavaScript pages

I spoke with Eliezer, who said he can try and do this post import. The only outstanding issues for the final import are now:

 1.  Move return values into their own section — if Max can. If not, Eliezer can create the section and we can move it manually.
 2.  Move the content currently in the javascript namespace into the Meta:* namespace.

Max & Eliezer: would you kindly let us know if this isn’t the case?

Thanks much!

J

-------------------
Julee Burdekin
Content Strategist
Adobe Web Platform
@adobejulee
julee@adobe.com

From: PhistucK <phistuck@gmail.com<mailto:phistuck@gmail.com>>
Date: Tuesday, January 28, 2014 at 10:41 AM
To: Doug Schepers <schepers@w3.org<mailto:schepers@w3.org>>
Cc: Max Polk <maxpolk@gmail.com<mailto:maxpolk@gmail.com>>, Eliot Graff <Eliot.Graff@microsoft.com<mailto:Eliot.Graff@microsoft.com>>, Eliezer Bernart <eliezer.bernart@gmail.com<mailto:eliezer.bernart@gmail.com>>, julee <jburdeki@adobe.com<mailto:jburdeki@adobe.com>>, Renoir Boulanger <renoir@w3.org<mailto:renoir@w3.org>>, WebPlatform Public List <public-webplatform@w3.org<mailto:public-webplatform@w3.org>>
Subject: Re: Attribution to MSDN on JavaScript pages

If doing this after the fact (but still automatically) is very much possible and as easy, I have no problem with such an approach.
If it is one of those things that would eventually be forgotten (or less prioritized and thus delayed for years), then I think this should delay the import.

Perhaps this is not such a big issue for everyone else, I do not know.


☆PhistucK


On Tue, Jan 28, 2014 at 8:17 PM, Doug Schepers <schepers@w3.org<mailto:schepers@w3.org>> wrote:
Hi, PhistucK–

It's not clear to me what alternative you're proposing that should delay the import.

I would prefer to go forward with the import and solve this afterward, in whatever way is most efficient.

Regards-
-Doug


On 1/28/14 9:52 AM, PhistucK wrote:
Oh, that is a very frustrating work. I did as much as I could with /dom
and it was a real pain in the ass to do when the information seems to be
structured so well to be done automatically.


☆*PhistucK*


On Tue, Jan 28, 2014 at 7:14 PM, Doug Schepers <schepers@w3.org<mailto:schepers@w3.org>
<mailto:schepers@w3.org<mailto:schepers@w3.org>>> wrote:

    Hi, PhistucK–

    While I'm sympathetic to your reasoning, I think that's something we
    can do manually after the import is done, rather than get it perfect
    from the start. We need to get closure on this import.

    Regards-
    -Doug


    On 1/28/14 1:52 AM, PhistucK wrote:

        Why are the members listed manually instead of being drawn from the
        hierarchy or from a property like in /dom?

        For example -
        http://docs.webplatform.org/__wiki/dom/CharacterData


        <http://docs.webplatform.org/wiki/dom/CharacterData>


        ☆*PhistucK*



        On Tue, Jan 28, 2014 at 9:17 AM, Max Polk <maxpolk@gmail.com<mailto:maxpolk@gmail.com>
        <mailto:maxpolk@gmail.com<mailto:maxpolk@gmail.com>>
        <mailto:maxpolk@gmail.com<mailto:maxpolk@gmail.com> <mailto:maxpolk@gmail.com<mailto:maxpolk@gmail.com>>>> wrote:

             On 1/25/2014 5:21 PM, Max Polk wrote:

                 I discovered a scheme to obtain all the original urls
            for the
                 JavaScript reference pages


             Done.   A new round of imports has completed.  The pages
        should all
             have links back to the correct article now.  Also, now using
             JS_Syntax_Format template instead of Js_Object_Format, per
        direction
             from Eliezer.

             At this point I have no outstanding issues.

             I noticed a small glitch, there are a few tables that seem
        to have
             gotten munged such as the Number page's "Properties" and
        "Methods"
             tables:

        http://docs.webplatform.org/__test/javascript/Number


        <http://docs.webplatform.org/test/javascript/Number>

             Half of the links to subpages point to the Object subpage
        instead of
             the Number subpage (like Object/constructor instead of
             Number/constructor) and would need manual updates after the
        import.
             I'm thinking this was an artifact created during the mass page
             renaming that went through several rounds.  All the right
        pages are
             there, just these two tables seem off in this one page.
          Maybe we
             need to spot check other tables to make sure it's localized
        and not
             widespread.  I apologize, we had lots of regex replacements
        going on
             and it must have slipped through my fingers.