Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start initial base #2

Open
wants to merge 5 commits into
base: master
from
Open

Start initial base #2

wants to merge 5 commits into from

Conversation

@raphamorim
Copy link
Member

raphamorim commented Sep 6, 2015

  • Page about Globalize API Documention
  • Entries
    • Docs over Core module
    • Docs over Date module
    • Docs over Message module
    • Docs over Number module
    • Docs over Currency module
    • Docs over Plural module
    • Docs over Relative time module

What do you think guys? Can I proceed?
Reference: #1

@jquerybot jquerybot added the CLA: Error label Sep 6, 2015
@arthurvr
Copy link
Member

arthurvr commented Sep 6, 2015

Can you sign the CLA?

Let's hear what @rxaviers thinks, but I'd prefer all those different pages in separate PRs so we can separately review and land them.

@rxaviers
Copy link
Member

rxaviers commented Sep 6, 2015

Hi @raphamorim,

About CLA, check your commit vs. signed name: "Raphael H. Amorim" vs "Raphael Amorim" Details here.

@arthurvr has a good idea. We could break this work in several different PRs.

Perhaps for the first PR, let's try getting Home and one of the API Entries complete. Then, the next PRs are going to be more straightforward implementations extending your initial work.

What do you think? Thanks so far!

@jquerybot jquerybot added CLA: Valid and removed CLA: Error labels Sep 6, 2015
@raphamorim
Copy link
Member Author

raphamorim commented Sep 6, 2015

Yeah, I realized the problem later. But I was not able to change the name.

I agree about implementation. I will finish the Core API. Then we validate this PR to proceed to a next PR.

@raphamorim
Copy link
Member Author

raphamorim commented Sep 9, 2015

Hi, can you guys check the changes? (cc:// @rxaviers, @arthurvr )

  1. In Globalize.locale adds CLDR instance as available parameter?
  2. It's necessary to document the new Globalize from Core Api?
@rxaviers
Copy link
Member

rxaviers commented Sep 10, 2015

@raphamorim, reviewing your change is o my TODO...

@raphamorim
Copy link
Member Author

raphamorim commented Sep 10, 2015

:) :octocat:

@rxaviers rxaviers mentioned this pull request Sep 10, 2015
0 of 2 tasks complete
@@ -1,4 +1,5 @@
<categories>
<category name="Uncategorized" slug="uncategorized"/>
<category name="Uncategorized" slug="uncategorized"></category>
<category name="Configuration and Utilities" slug="config"></category>

This comment has been minimized.

@arthurvr

arthurvr Sep 11, 2015 Member

It's up to @rxaviers, but shouldn't there be two categories here: Configuration and Utilities? Then it's also perfectly possible to add two categories on one article.

Also, I know it's nitpicky, but could you please fix the indentation in all these files? You used spaces while we use tabs.

This comment has been minimized.

@raphamorim

raphamorim Sep 13, 2015 Author Member

Yeah, the identation I'll fix. Sorry about that.

Configuration and Utilities 'cause is the standart for others jQuery docs, similar case is qUnit docs.

This comment has been minimized.

@rxaviers

rxaviers Sep 15, 2015 Member

/cc @jzaefferer and @scottgonzalez for their input about the naming.

This comment has been minimized.

@rxaviers

rxaviers Sep 15, 2015 Member

@raphamorim, which content are you going to be put into Configuration and Utilities? I think it will be clear to figure the naming after knowing that first.

This comment has been minimized.

@raphamorim

raphamorim Sep 16, 2015 Author Member

It would be for initialization and additional methods. But I have no problems as changing the name, just follow the QUnit model. We can change here :)

This comment has been minimized.

@scottgonzalez

scottgonzalez Sep 25, 2015 Member

Configuration and Utilities 'cause is the standart for others jQuery docs, similar case is qUnit docs.

Definitely not a standard just because it exists in a single site. If anything, the standard would be for separate categories as other projects have a Utilities category. I'd actually say that QUnit should split their category in two, since it's almost exclusively utilities already.

This comment has been minimized.

@raphamorim

raphamorim Sep 27, 2015 Author Member

Got it. So in this case what would be the category name?

This comment has been minimized.

@scottgonzalez

scottgonzalez Sep 28, 2015 Member

Anything related to configuration would be in Configuration, and utility methods would be in Utilities. Though I think you're best bet is to make a list of what will be documented, then create categories based on the content.

@rxaviers
Copy link
Member

rxaviers commented Sep 15, 2015

@raphamorim,

In Globalize.locale adds CLDR instance as available parameter?

Yeap, Globalize.locale allows three different uses:

  • argument to be omitted Globalize.locale(), which returns the current default locale.
  • Globalize.locale(locale), where locale is a String, which will set default locale.
  • Globalize.locale(cldr), where cldr is an instance of https://github.com/rxaviers/cldrjs, which will set default locale similarly as above.

It's necessary to document the new Globalize from Core Api?

Yeap.

]]></code>
</example>
<category slug="config"/>
</entry>

This comment has been minimized.

@rxaviers

rxaviers Sep 15, 2015 Member

In general, it concerns me too much having to maintain documentation content in XML format.

@scottgonzalez can this be generated automatically from markdown?

This comment has been minimized.

@arthurvr

arthurvr Sep 16, 2015 Member

I don't really like it eighter. I don't really think anyone likes it, but it's easy to get used to. Scott knows these things way better than I, but I believe things like categories and signatures are difficult in markdown (at least using the current grunt-jquery-content setup). Personally I find markdown in general difficult to keep things consistent and structured enough for API docs.

This comment has been minimized.

@scottgonzalez

scottgonzalez Sep 25, 2015 Member

Nope. It's all XML. As @arthurvr mentions, this is a necessary evil since API docs are highly structured.

This comment has been minimized.

@raphamorim
Copy link
Member Author

raphamorim commented Sep 27, 2015

@rxaviers so I proceed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.