Commit Graph

22 Commits

Author SHA1 Message Date
Alex Eagle 422eb14dc0 build: remove vendored Babel typings (#33226)
These were getting included in the @angular/localize package.
Instead, patch the upstream files to work with TS typeRoots option

See bazelbuild/rules_nodejs#1033

PR Close #33226
2019-10-17 18:45:52 -04:00
Matias Niemelä e9ee6859e3 revert: build: remove vendored Babel typings (#33176) (#33215)
This reverts commit 4c63e6ba04.

PR Close #33215
2019-10-17 00:24:25 -04:00
Alex Eagle 4c63e6ba04 build: remove vendored Babel typings (#33176)
These were getting included in the @angular/localize package.
Instead, patch the upstream files to work with TS typeRoots option

See bazelbuild/rules_nodejs#1033

PR Close #33176
2019-10-16 12:54:28 -04:00
Pete Bacon Darwin f433d6604b feat(ivy): i18n - support source locale inlining (#33101)
Add a new flag to `localize-translate` that allows the
source locale to be specified. When this locale is
provided an extra copy of the files is made for this
locale where the is no translation but all the calls to
`$localize` are stripped out.

Resolves FW-1623

PR Close #33101
2019-10-14 20:32:57 +00:00
Pete Bacon Darwin 83425fa119 fix(ivy): i18n - support lazy-load template string helpers (#33097)
There are numerous approaches to downlevelling backticked
template strings to ES5.
This commit handles yet another one that Babel applies.

PR Close #33097
2019-10-14 16:33:39 +00:00
Pete Bacon Darwin 1845faa66b fix(ivy): i18n - strip meta blocks from untranslated messages (#33097)
If a message has no translation then we should still strip the
meta blocks from the message parts before adding back to the
AST.

PR Close #33097
2019-10-14 16:33:38 +00:00
Pete Bacon Darwin d617373a76 refactor(ivy): i18n - change `unwrapMessagePartsFromLocalizeCall` to accept a `NodePath` (#33097)
In Babel `NodePath` objects have more useful information available than
simple AST nodes. But they are more difficult to create, especially for testing.

This commit prepares the way for parsing more complex code downlevelling
scenarios.

PR Close #33097
2019-10-14 16:33:38 +00:00
Pete Bacon Darwin 90855f331f refactor(ivy): i18n - rename `I18nError` to `TranslationParserError` (#32881)
This closer reflects what caused the error.

PR Close #32881
2019-10-09 13:19:38 -07:00
Pete Bacon Darwin 2cdb3a079d feat(ivy): i18n - implement compile-time inlining (#32881)
This commit implements a tool that will inline translations and generate
a translated copy of a set of application files from a set of translation
files.

PR Close #32881
2019-10-09 13:19:38 -07:00
cexbrayat d18289fa9c fix(ivy): missing schematics field in localize package (#33025)
The schematics added in #32791 is currently failing as the package.json does not reference it.

```
> ng add @angular/localize@9.0.0-next.9
+ @angular/localize@9.0.0-next.9
added 1 package from 1 contributor in 6.745s
Installed packages for tooling via npm.
The package that you are trying to add does not support schematics. You can try using a different version of the package or contact the package author to add ng-add support.
```

PR Close #33025
2019-10-07 10:21:29 -07:00
Pete Bacon Darwin 9188751adc fix(ivy): i18n - do not render message ids unnecessarily (#32867)
In an attempt to be compatible with previous translation files
the Angular compiler was generating instructions that always
included the message id. This was because it was not possible
to accurately re-generate the id from the calls to `$localize()` alone.

In line with https://hackmd.io/EQF4_-atSXK4XWg8eAha2g this
commit changes the compiler so that it only renders ids if they are
"custom" ones provided by the template author.

NOTE:

When translating messages generated by the Angular compiler
from i18n tags in templates, the `$localize.translate()` function
will compute message ids, if no custom id is provided, using a
common digest function that only relies upon the information
available in the `$localize()` calls.

This computed message id will not be the same as the message
ids stored in legacy translation files. Such files will need to be
migrated to use the new common digest function.

This only affects developers who have been trialling `$localize`, have
been calling `loadTranslations()`, and are not exclusively using custom
ids in their templates.

PR Close #32867
2019-10-02 14:52:00 -07:00
Pete Bacon Darwin d24ade91b8 fix(ivy): i18n - support colons in $localize metadata (#32867)
Metadata blocks are delimited by colons. Previously the code naively just
looked for the next colon in the string as the end marker.

This commit supports escaping colons within the metadata content.
The Angular compiler has been updated to add escaping as required.

PR Close #32867
2019-10-02 14:52:00 -07:00
Pete Bacon Darwin 97d5700456 fix(ivy): i18n - better translation warnings (#32867)
The missing translation and invalid placeholder warnings now contain the
"meaning" if one was provided.

PR Close #32867
2019-10-02 14:52:00 -07:00
Pete Bacon Darwin 601f87c2ec fix(ivy): i18n - throw an error if a translation contains an invalid placeholder (#32867)
Previously if a translation contains a placeholder that
does not exist in the message being translated, that
placeholder is evaluated as `undefined`.

Translations should never contain such placeholder names
so now `translate` will throw a helpful error in instead.

PR Close #32867
2019-10-02 14:52:00 -07:00
Filipe Silva e41cbfb585 feat(ivy): support ng-add in localize package (#32791)
PR Close #32791
2019-09-27 13:15:02 -07:00
cexbrayat f1b1de9a3d fix(ivy): i18n - start generated placeholder name at `PH` (#32493)
Currently the expressions used in a template string are automatically named
`PH_1`, `PH_2`, etc. Whereas interpolations used in i18n templates generate
placeholders automatically named `INTERPOLATION`, `INTERPOLATION_1`, etc.

This commit aligns the behaviors by starting the generated placeholder
names for expressions at `PH`, then `PH_1`, etc.

It also documents this behavior in the documentation of `$localize` as
it was not mentioned before.

PR Close #32493
2019-09-17 15:13:30 -07:00
Pete Bacon Darwin 357aa4a097 fix(ivy): i18n - use `MessageId` for matching translations (#32594)
As discussed in https://hackmd.io/33M5Wb-JT7-0fneA0JuHPA `SourceMessage`
strings are not sufficient for matching translations.

This commit updates `@angular/localize` to use `MessageId`s for translation
matching instead.

Also the run-time translation will now log a warning to the console if a
translation is missing.

BREAKING CHANGE:

Translations (loaded via the `loadTranslations()` function) must now use
`MessageId` for the translation key rather than the previous `SourceMessage`
string.

PR Close #32594
2019-09-17 09:17:44 -07:00
Pete Bacon Darwin 870d189433 refactor(ivy): i18n - run-time translation API to use message-id (#32594)
Previously the translation key used for translations was the `SourceMessage`
but it turns out that this is insufficient because "meaning" and "custom-id"
metadata affect the translation key.

Now run-time translation is keyed off the `MessageId`.

PR Close #32594
2019-09-17 09:17:44 -07:00
Pete Bacon Darwin c7abb7d196 feat(ivy): i18n - add syntax support for `$localize` metadata block (#32594)
This commit documents and extends the basic `$localize`
implementation to support adding a metadata block to the
start of a tagged message.

All the "pass-though" version does is to strip this block out,
similar to what it does to placeholder name blocks.

PR Close #32594
2019-09-17 09:17:44 -07:00
Pete Bacon Darwin fd62ed66e3 test(ivy): i18n - re-enable skipped tests (#32594)
The `packages/localize/test/utils` folder was not being
included in the unit tests because the glob for the spec
files was only looking in the top level folder.

PR Close #32594
2019-09-17 09:17:44 -07:00
Pete Bacon Darwin 2bf5606bbe feat(ivy): i18n - reorganize entry-points for better reuse (#32488)
This is a refactoring that moves the source code around to provide a better
platform for adding the compile-time inlining.

1. Move the global side-effect import from the primary entry-point to a
   secondary entry-point @angular/localize/init.

   This has two benefits: first it allows the top level entry-point to
   contain tree-shakable shareable code; second it gives the side-effect
   import more of an "action" oriented name, which indicates that importing
   it does something tangible

2. Move all the source code into the top src folder, and import the localize
   related functions into the localize/init/index.ts entry-point.

   This allows the different parts of the package to share code without
   a proliferation of secondary entry-points (i.e. localize/utils).

3. Avoid publicly exporting any utilities at this time - the only public
   API at this point are the global `$localize` function and the two runtime
   helpers `loadTranslations()` and `clearTranslations()`.
   This does not mean that we will not expose additional helpers for 3rd
   party tooling in the future, but it avoid us preemptively exposing
   something that we might want to change in the near future.

Notes:

It is not possible to have the `$localize` code in the same Bazel package
as the rest of the code. If we did this, then the bundled `@angular/localize/init`
entry-point code contains all of the helper code, even though most of it is not used.

Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn`
and `TranslateFn`) defined in the `@angular/localize/init` entry-point because
these types are needed for the runtime code, which is inside the primary
entry-point. Importing them from `@angular/localize/init` would run the
side-effect.

The solution is to have a Bazel sub-package at `//packages/localize/src/localize`
which contains these types and the `$localize` function implementation.
The primary `//packages/localize` entry-point imports the types without
any side-effect.
The secondary `//packages/localize/init` entry-point imports the `$localize`
function and attaches it to the global scope as a side-effect, without
bringing with it all the other utility functions.

BREAKING CHANGES:

The entry-points have changed:

* To attach the `$localize` function to the global scope import from
`@angular/localize/init`. Previously it was `@angular/localize`.

* To access the `loadTranslations()` and `clearTranslations()` functions,
import from `@angular/localize`. Previously it was `@angular/localize/run_time`.

PR Close #32488
2019-09-12 15:35:34 -07:00
Pete Bacon Darwin b21397bde9 feat(ivy): implement `$localize()` global function (#31609)
PR Close #31609
2019-08-30 12:53:25 -07:00