This repository has been archived by the owner on Dec 21, 2021. It is now read-only.
Start initial base #2
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,5 @@ | ||
| <categories> | ||
| <category name="Uncategorized" slug="uncategorized"></category> | ||
| <category name="Configuration and Utilities" slug="config"></category> | ||
| <category name="All" slug="all"></category> | ||
| </categories> | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,100 @@ | ||
| <?xml version="1.0"?> | ||
| <?xml-stylesheet type="text/xsl" href="../entries2html.xsl" ?> | ||
| <entry type="method" name="Globalize.load"> | ||
| <title>Globalize.load()</title> | ||
| <signature> | ||
| <argument name="cldrJSONData" type="Object"> | ||
| <desc>A JSON object with CLDR data.</desc> | ||
| </argument> | ||
| </signature> | ||
| <desc>This method allows you to load CLDR JSON locale data.</desc> | ||
| <longdesc> | ||
| <p> | ||
| This method can be called as many time as needed. All passed JSON objects are deeply merged internally. | ||
| </p> | ||
| </longdesc> | ||
| <example> | ||
| <desc>Load CLDR data.</desc> | ||
| <code><![CDATA[ | ||
| Globalize.load({ | ||
| "main": { | ||
| "en": { | ||
| "identity": { | ||
| "version": { | ||
| "_cldrVersion": "25", | ||
| "_number": "$Revision: 91 $" | ||
| }, | ||
| "generation": { | ||
| "_date": "$Date: 2014-03-13 22:27:12 -0500 (Thu, 13 Mar 2014) $" | ||
| }, | ||
| "language": "en" | ||
| }, | ||
| "dates": { | ||
| "calendars": { | ||
| "gregorian": { | ||
| "months": { | ||
| "format": { | ||
| "abbreviated": { | ||
| "1": "Jan", | ||
| "2": "Feb", | ||
| "3": "Mar", | ||
| "4": "Apr", | ||
| "5": "May", | ||
| "6": "Jun", | ||
| "7": "Jul", | ||
| "8": "Aug", | ||
| "9": "Sep", | ||
| "10": "Oct", | ||
| "11": "Nov", | ||
| "12": "Dec" | ||
| } | ||
| } | ||
| }, | ||
| "dayPeriods": { | ||
| "format": { | ||
| "wide": { | ||
| "am": "AM", | ||
| "am-alt-variant": "am", | ||
| "noon": "noon", | ||
| "pm": "PM", | ||
| "pm-alt-variant": "pm" | ||
| } | ||
| } | ||
| }, | ||
| "dateFormats": { | ||
| "medium": "MMM d, y" | ||
| }, | ||
| "timeFormats": { | ||
| "medium": "h:mm:ss a", | ||
| }, | ||
| "dateTimeFormats": { | ||
| "medium": "{1}, {0}" | ||
| } | ||
| } | ||
| } | ||
| }, | ||
| "numbers": { | ||
| "defaultNumberingSystem": "latn", | ||
| "symbols-numberSystem-latn": { | ||
| "group": "," | ||
| }, | ||
| "decimalFormats-numberSystem-latn": { | ||
| "standard": "#,##0.###" | ||
| } | ||
| } | ||
| } | ||
| }, | ||
| "supplemental": { | ||
| "version": { | ||
| "_cldrVersion": "25", | ||
| "_number": "$Revision: 91 $" | ||
| }, | ||
| "likelySubtags": { | ||
| "en": "en-Latn-US", | ||
| } | ||
| } | ||
| }); | ||
| ]]></code> | ||
| </example> | ||
| <category slug="config"/> | ||
| </entry> | ||
|
There was a problem hiding this comment. In general, it concerns me too much having to maintain documentation content in XML format. @scottgonzalez can this be generated automatically from markdown? There was a problem hiding this comment. 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. There was a problem hiding this comment. Nope. It's all XML. As @arthurvr mentions, this is a necessary evil since API docs are highly structured. |
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| <?xml version="1.0"?> | ||
| <?xml-stylesheet type="text/xsl" href="../entries2html.xsl" ?> | ||
| <entry type="method" name="Globalize.locale"> | ||
| <title>Globalize.locale()</title> | ||
| <signature> | ||
| <argument name="locale" type="String"> | ||
| <desc>The locale string, eg: <strong>en</strong>, <strong>pt-BR</strong>, or <strong>zh-Hant-TW</strong>. </desc> | ||
| </argument> | ||
| </signature> | ||
| <desc>Set default locale, or get it if locale argument is omitted.</desc> | ||
| <longdesc> | ||
| <p> | ||
| An application that supports globalization and/or localization will need to have a way to determine the user's preference. Attempting to automatically determine the appropriate locale is useful, but it is good practice to always offer the user a choice, by whatever means. | ||
| </p> | ||
| <p> | ||
| Whatever your mechanism, it is likely that you will have to correlate the user's preferences with the list of locale data supported in the app. This method allows you to select the best match given the locale data that you have included and to set the Globalize locale to the one which the user prefers. | ||
| </p> | ||
| <p> | ||
| LanguageMatching TBD (CLDR's spec <a href="http://www.unicode.org/reports/tr35/#LanguageMatching">http://www.unicode.org/reports/tr35/#LanguageMatching</a>). | ||
| </p> | ||
| </longdesc> | ||
| <example> | ||
| <desc>Prior to using this function, you must load cldr/supplemental/likelySubtags.json. Read CLDR content if you need more information.</desc> | ||
| <code><![CDATA[ | ||
| // Set "pt" as our default locale. | ||
| Globalize.locale( "pt" ); | ||
|
|
||
| // Get default locale. | ||
| Globalize.locale(); | ||
| // > { | ||
| // attributes: { | ||
| // "languageId": "pt", | ||
| // "maxLanguageId": "pt_Latn_BR", | ||
| // "language": "pt", | ||
| // "script": "Latn", | ||
| // "territory": "BR", | ||
| // "region": "BR" | ||
| // }, | ||
| // some more stuff... | ||
| // } | ||
| ]]></code> | ||
| </example> | ||
| <category slug="config"/> | ||
| </entry> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| <script>{ | ||
| "title": "Globalize API Documentation" | ||
| }</script> | ||
|
|
||
| <p>Globalize is a JavaScript library for internationalization and localization that leverages the official Unicode CLDR JSON data.</p> | ||
|
|
||
| <p>To get started, use the search at the top of the page, view the | ||
| <a href="/category/all/">full listing of entries</a>, or browse by | ||
| category from the sidebar.</p> |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's up to @rxaviers, but shouldn't there be two categories here:
ConfigurationandUtilities? 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the identation I'll fix. Sorry about that.
ConfigurationandUtilities'cause is the standart for others jQuery docs, similar case is qUnit docs.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @jzaefferer and @scottgonzalez for their input about the naming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. So in this case what would be the category name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.