Olivier Combe 079d884b6c feat(common): drop use of the Intl API to improve browser support (#18284)
BREAKING CHANGE: Because of multiple bugs and browser inconsistencies, we have dropped the intl api in favor of data exported from the Unicode Common Locale Data Repository (CLDR).
Unfortunately we had to change the i18n pipes (date, number, currency, percent) and there are some breaking changes.

1. I18n pipes
* Breaking change:
  - By default Angular now only contains locale data for the language `en-US`, if you set the value of `LOCALE_ID` to another locale, you will have to import new locale data for this language because we don't use the intl API anymore.

* Features:
  - you don't need to use the intl polyfill for Angular anymore.
  - all i18n pipes now have an additional last parameter `locale` which allows you to use a specific locale instead of the one defined in the token `LOCALE_ID` (whose value is `en-US` by default).
  - the new locale data extracted from CLDR are now available to developers as well and can be used through an API (which should be especially useful for library authors).
  - you can still use the old pipes for now, but their names have been changed and they are no longer included in the `CommonModule`. To use them, you will have to import the `DeprecatedI18NPipesModule` after the `CommonModule` (the order is important):

  ```ts
  import { NgModule } from '@angular/core';
  import { CommonModule, DeprecatedI18NPipesModule } from '@angular/common';

  @NgModule({
    imports: [
      CommonModule,
      // import deprecated module after
      DeprecatedI18NPipesModule
    ]
  })
  export class AppModule { }
  ```

  Dont forget that you will still need to import the intl API polyfill if you want to use those deprecated pipes.

2. Date pipe
* Breaking changes:
  - the predefined formats (`short`, `shortTime`, `shortDate`, `medium`, ...) now use the patterns given by CLDR (like it was in AngularJS) instead of the ones from the intl API. You might notice some changes, e.g. `shortDate` will be `8/15/17` instead of `8/15/2017` for `en-US`.
  - the narrow version of eras is now `GGGGG` instead of `G`, the format `G` is now similar to `GG` and `GGG`.
  - the narrow version of months is now `MMMMM` instead of `L`, the format `L` is now the short standalone version of months.
  - the narrow version of the week day is now `EEEEE` instead of `E`, the format `E` is now similar to `EE` and `EEE`.
  - the timezone `z` will now fallback to `O` and output `GMT+1` instead of the complete zone name (e.g. `Pacific Standard Time`), this is because the quantity of data required to have all the zone names in all of the existing locales is too big.
  - the timezone `Z` will now output the ISO8601 basic format, e.g. `+0100`, you should now use `ZZZZ` to get `GMT+01:00`.

  | Field type | Format        | Example value         | v4 | v5            |
  |------------|---------------|-----------------------|----|---------------|
  | Eras       | Narrow        | A for AD              | G  | GGGGG         |
  | Months     | Narrow        | S for September       | L  | MMMMM         |
  | Week day   | Narrow        | M for Monday          | E  | EEEEE         |
  | Timezone   | Long location | Pacific Standard Time | z  | Not available |
  | Timezone   | Long GMT      | GMT+01:00             | Z  | ZZZZ          |

* Features
  - new predefined formats `long`, `full`, `longTime`, `fullTime`.
  - the format `yyy` is now supported, e.g. the year `52` will be `052` and the year `2017` will be `2017`.
  - standalone months are now supported with the formats `L` to `LLLLL`.
  - week of the year is now supported with the formats `w` and `ww`, e.g. weeks `5` and `05`.
  - week of the month is now supported with the format `W`, e.g. week `3`.
  - fractional seconds are now supported with the format `S` to `SSS`.
  - day periods for AM/PM now supports additional formats `aa`, `aaa`, `aaaa` and `aaaaa`. The formats `a` to `aaa` are similar, while `aaaa` is the wide version if available (e.g. `ante meridiem` for `am`), or equivalent to `a` otherwise, and `aaaaa` is the narrow version (e.g. `a` for `am`).
  - extra day periods are now supported with the formats `b` to `bbbbb` (and `B` to `BBBBB` for the standalone equivalents), e.g. `morning`, `noon`, `afternoon`, ....
  - the short non-localized timezones are now available with the format `O` to `OOOO`. The formats `O` to `OOO` will output `GMT+1` while the format `OOOO` will be `GMT+01:00`.
  - the ISO8601 basic time zones are now available with the formats `Z` to `ZZZZZ`. The formats `Z` to `ZZZ` will output `+0100`, while the format `ZZZZ` will be `GMT+01:00` and `ZZZZZ` will be `+01:00`.

* Bug fixes
  - the date pipe will now work exactly the same across all browsers, which will fix a lot of bugs for safari and IE.
  - eras can now be used on their own without the date, e.g. the format `GG` will be `AD` instead of `8 15, 2017 AD`.

3. Currency pipe
* Breaking change:
  - the default value for `symbolDisplay` is now `symbol` instead of `code`. This means that by default you will see `$4.99` for `en-US` instead of `USD4.99` previously.

* Deprecation:
  - the second parameter of the currency pipe (`symbolDisplay`) is no longer a boolean, it now takes the values `code`, `symbol` or `symbol-narrow`. A boolean value is still valid for now, but it is deprecated and it will print a warning message in the console.

* Features:
  - you can now choose between `code`, `symbol` or `symbol-narrow` which gives you access to more options for some currencies (e.g. the canadian dollar with the code `CAD` has the symbol `CA$` and the symbol-narrow `$`).

4. Percent pipe
* Breaking change
  - if you don't specify the number of digits to round to, the local format will be used (and it usually rounds numbers to 0 digits, instead of not rounding previously), e.g. `{{ 3.141592 | percent }}` will output `314%` for the locale `en-US` instead of `314.1592%` previously.

Fixes #10809, #9524, #7008, #9324, #7590, #6724, #3429, #17576, #17478, #17319, #17200, #16838, #16624, #16625, #16591, #14131, #12632, #11376, #11187

PR Close #18284
2017-08-22 15:43:58 -05:00
..

Angular documentation project (https://angular.io)

Everything in this folder is part of the documentation project. This includes

  • the web site for displaying the documentation
  • the dgeni configuration for converting source files to rendered files that can be viewed in the web site.
  • the tooling for setting up examples for development; and generating plunkers and zip files from the examples.

Developer tasks

We use yarn to manage the dependencies and to run build tasks. You should run all these tasks from the angular/aio folder. Here are the most important tasks you might need to use:

  • yarn - install all the dependencies.

  • yarn setup - Install all the dependencies, boilerplate, plunkers, zips and runs dgeni on the docs.

  • yarn start - run a development web server that watches the files; then builds the doc-viewer and reloads the page, as necessary.

  • yarn serve-and-sync - run both the docs-watch and start in the same console.

  • yarn lint - check that the doc-viewer code follows our style rules.

  • yarn test - watch all the source files, for the doc-viewer, and run all the unit tests when any change.

  • yarn e2e - run all the e2e tests for the doc-viewer.

  • yarn docs - generate all the docs from the source files.

  • yarn docs-watch - watch the Angular source and the docs files and run a short-circuited doc-gen for the docs that changed.

  • yarn docs-lint - check that the doc gen code follows our style rules.

  • yarn docs-test - run the unit tests for the doc generation code.

  • yarn boilerplate:add - generate all the boilerplate code for the examples, so that they can be run locally.

  • yarn boilerplate:remove - remove all the boilerplate code that was added via yarn boilerplate:add.

  • yarn generate-plunkers - generate the plunker files that are used by the live-example tags in the docs.

  • yarn generate-zips - generate the zip files from the examples. Zip available via the live-example tags in the docs.

  • yarn example-e2e - run all e2e tests for examples

    • yarn example-e2e -- --setup - force webdriver update & other setup, then run tests
    • yarn example-e2e -- --filter=foo - limit e2e tests to those containing the word "foo"
  • yarn build-ie-polyfills - generates a js file of polyfills that can be loaded in Internet Explorer.

Using ServiceWorker locally

Since abb36e3cb, running yarn start -- --prod will no longer set up the ServiceWorker, which would require manually running yarn sw-manifest and yarn sw-copy (something that is not possible with webpack serving the files from memory).

If you want to test ServiceWorker locally, you can use yarn build and serve the files in dist/ with yarn http-server -- dist -p 4200.

For more details see #16745.

Guide to authoring

There are two types of content in the documentatation:

  • API docs: descriptions of the modules, classes, interfaces, decorators, etc that make up the Angular platform. API docs are generated directly from the source code. The source code is contained in TypeScript files, located in the angular/packages folder. Each API item may have a preceding comment, which contains JSDoc style tags and content. The content is written in markdown.

  • Other content: guides, tutorials, and other marketing material. All other content is written using markdown in text files, located in the angular/aio/content folder. More specifically, there are sub-folders that contain particular types of content: guides, tutorial and marketing.

We use the dgeni tool to convert these files into docs that can be viewed in the doc-viewer.

The Authors Style Guide prescribes guidelines for writing guide pages, explains how to use the documentation classes and components, and how to markup sample source code to produce code snippets.

Generating the complete docs

The main task for generating the docs is yarn docs. This will process all the source files (API and other), extracting the documentation and generating JSON files that can be consumed by the doc-viewer.

Partial doc generation for editors

Full doc generation can take up to one minute. That's too slow for efficient document creation and editing.

You can make small changes in a smart editor that displays formatted markdown:

In VS Code, Cmd-K, V opens markdown preview in side pane; Cmd-B toggles left sidebar

You also want to see those changes displayed properly in the doc viewer with a quick, edit/view cycle time.

For this purpose, use the yarn docs-watch task, which watches for changes to source files and only re-processes the the files necessary to generate the docs that are related to the file that has changed. Since this task takes shortcuts, it is much faster (often less than 1 second) but it won't produce full fidelity content. For example, links to other docs and code examples may not render correctly. This is most particularly noticed in links to other docs and in the embedded examples, which may not always render correctly.

The general setup is as follows:

  • Open a terminal, ensure the dependencies are installed; run an initial doc generation; then start the doc-viewer:
yarn
yarn docs
yarn start
  • Open a second terminal and start watching the docs
yarn docs-watch
  • Open a browser at https://localhost:4200/ and navigate to the document on which you want to work. You can automatically open the browser by using yarn start -- -o in the first terminal.

  • Make changes to the page's associated doc or example files. Every time a file is saved, the doc will be regenerated, the app will rebuild and the page will reload.