Start initial base

[raphamorim]

• 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

[arthurvr]

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]

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!

[raphamorim]

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]

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]

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

[raphamorim]

:)

[arthurvr]

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.

[raphamorim]

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.

[rxaviers]

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

[rxaviers]

@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.

[raphamorim]

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

[scottgonzalez]

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.

[raphamorim]

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

[scottgonzalez]

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]

@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.

[rxaviers]

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

@scottgonzalez can this be generated automatically from markdown?

[arthurvr]

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.

[scottgonzalez]

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

[rxaviers]

Thx

[raphamorim]

@rxaviers so I proceed?