The ARB format is a JSON file containing an object where the keys are the
message ids and the values are the translations.
It is extensible because it can also contain metadata about each message.
For example:
```
{
"@@locale": "...",
"message-id": "Translated message string",
"@message-id": {
"type": "text",
"description": "Some description text",
"x-locations": [{ "start": {"line": 23, "column": 145}, "file": "some/file.ts" }]
},
}
```
For more information, see:
https://github.com/google/app-resource-bundle/wiki/ApplicationResourceBundleSpecification
PR Close#36795
ngtsc has a robust suite of testing utilities, designed for in-memory
testing of a TypeScript compiler. Previously these utilities lived in the
`test` directory for the compiler-cli package.
This commit moves those utilities to an `ngtsc/testing` package, enabling
them to be depended on separately and opening the door for using them from
the upcoming language server testing infrastructure.
As part of this refactoring, the `fake_core` package (a lightweight API
replacement for @angular/core) is expanded to include functionality needed
for Language Service test use cases.
PR Close#39594
These free standing functions rely upon the "current" `FileSystem`,
but it is safer to explicitly pass the `FileSystem` into functions or
classes that need it.
Fixes#38711
PR Close#39006
A recent change to `@angular/localize` brought in the `AbsoluteFsPath` type
from the `@angular/compiler-cli`. But this brought along with it a reference
to NodeJS typings - specifically the `FileSystem` interface refers to the
`Buffer` type from NodeJS.
This affects compilation of `@angular/localize` code that will be run in
the browser - for example projects that reference `loadTranslations()`.
The compilation breaks if the NodeJS typings are not included in the build.
Clearly it is not desirable to have these typings included when the project
is not targeting NodeJS.
This commit replaces references to the NodeJS `Buffer` type with `Uint8Array`,
which is available across all platforms and is actually the super-class of
`Buffer`.
Fixes#38692
PR Close#38700
Previously the position of the error in a translation file when parsing
it was not displayed. Just the error message.
Now the position (line and column) and some context is displayed
along with the error messages.
Fixes#38377
PR Close#38673
This commit is a tidy up of the translate plugin unit tests, but also ensures
that the tests are run in the context of a mock FileSystem. This ensures
that the tests are resilient to future refactors of the plugins that will
require a FileSystem to be initialized.
PR Close#38536
Previously nested container placeholders (i.e. HTML elements) were
not being fully parsed from translation files. This resulted in bad
translation of messages that contain these placeholders.
Note that this causes the canonical message ID to change for
such messages. Currently all messages generated from
templates use "legacy" message ids that are not affected by
this change, so this fix should not be seen as a breaking change.
Fixes#38422
PR Close#38452
When loading a translation file we ask each `TranslationParser`
whether it can parse the file. Occasionally, this check can find
errors in the file that would be useful to the developer. For example
if the file has invalid XML.
This commit deprecates the previous `canParse()` method and replaces it
with a new `analyze()` method. This returns an object that includes a
boolean `canParse` and then either a `hint` if it can parse the file,
or a `diagnostics` object filled with any messages that can be used to
diagnose problems with the format of the file.
Closes #37901
PR Close#37909
This commit makes the leap from its own custom baked `FileUtils`
solution to the fully formed `FileSystem` that is used in the compiler-cli.
This makes testing more straightforward and helps to ensure that the tool
will work across operatings systems.
Also, going forward, it will allow the localize project access to other useful
code from the compiler-cli, such as source-map handling.
PR Close#36843
Previously only one translation file per locale could be loaded.
Now the user can specify multiple files per locale, and the translations
from each of these files will be merged together by message id.
The merging is on a first-wins approach. So if to you have three files
to be merged:
```
['a.xlf', 'b.xmb', 'c.json']
```
Then any message from `a.xlf` will be used rather than a message from `b.xmb`
or `c.json` and so on. In practice this means that you should put the files
in order of most important first, with "fallback" translations later.
PR Close#36792
XLIFF translation files can contain multiple `<file>` elements,
each of which contains translations. In ViewEngine all these
translations are merged into a single translation bundle.
Previously in Ivy only the translations from the last `<file>`
element were being loaded. Now all the translations from each
`<file>` are merged into a single translation bundle.
Fixes#35839
PR Close#35936
This commit improves the `canParse()` method to check that the file is
valid XML and has the expected root node. Previously it was relying upon
a regular expression to do this.
PR Close#35793
Previously, the `Xliff2TranslationParser` only matched files that had a narrow
choice of extensions (e.g. `xlf`) and also relied upon a regular expression
match of an optional XML namespace directive.
This commit relaxes the requirement on both of these and, instead, relies
upon parsing the file into XML and identifying an element of the form
`<xliff version="2.0">` which is the minimal requirement for such files.
PR Close#35793
Previously, the `Xliff1TranslationParser` only matched files that had a narrow
choice of extensions (e.g. `xlf`) and also relied upon a regular expression
match of an optional XML namespace directive.
This commit relaxes the requirement on both of these and, instead, relies
upon parsing the file into XML and identifying an element of the form
`<xliff version="1.2">` which is the minimal requirement for such files.
PR Close#35793
This modifies the internal (but shared with CLI) API for loading/parsing
translation files. Now the parsers will return a new `Diagnostics` object
along with any translations and locale extracted from the file.
It is up to the caller to decide what to do about this, if there are errors
it is suggested that an error is thrown, which is what the `TranslationLoader`
class does.
PR Close#35793
Some minification tooling modifies `$localize` calls
to contain a comma sequence of items, where the
cooked and raw values are assigned to variables.
This change improves our ability to recognize these
structures.
Fixes#35376
PR Close#35562
the test failures most likely result from the babel updates in the previous commit.
it does look like we lost the file path from the error message, which is something that we
should follow up no in a separate change.
PR Close#34974
The major one that affects the angular repo is the removal of the bootstrap attribute in nodejs_binary, nodejs_test and jasmine_node_test in favor of using templated_args --node_options=--require=/path/to/script. The side-effect of this is that the bootstrap script does not get the require.resolve patches with explicitly loading the targets _loader.js file.
PR Close#34736
The major one that affects the angular repo is the removal of the bootstrap attribute in nodejs_binary, nodejs_test and jasmine_node_test in favor of using templated_args --node_options=--require=/path/to/script. The side-effect of this is that the bootstrap script does not get the require.resolve patches with explicitly loading the targets _loader.js file.
PR Close#34589
The ViewEngine translation extractor does not convert `-` to `_` for
placeholders that represent custom elements. For example `<app-component>`
gets converted to placeholders like `START_TAG_APP-COMPONENT`.
In `$localize` placeholders are expected to be snake-case, not kebab-case.
So we must normalize them when parsing a translation file that might have
been created via the View Engine translation extractor.
The `$localize` extraction code will normalize these placeholders when
creating translation files in the first place.
Fixes#34151
PR Close#34155
The parser was accidentally reading the `target` tag
below the `alt-trans` target and overriding the correct
`target` tag.
(This already worked in `$localize` but a test has been
added to confirm.)
Fixes#33161
PR Close#33450
Each of the XML based `TranslationParsers` was providing its own
`MessageSerializer`, but they are all very similar. So these have been
consolidated into a single more generic `MessageSerializer.
As a result of this, the extra layers of folders in the project seemed
unnecessary, so they have been flattened.
PR Close#33444
Previously the target locale of a translation file had to be extracted
from the contents of the translation file. Therefore it was an error if
the translation file did not provide a target locale.
Now an array of locales can be provided via the `translationFileLocales`
option that overrides any target locale extracted from the file.
This allows us to support translation files that do not have a target
locale specified in their contents.
// FW-1644
Fixes#33323
PR Close#33381
During compile-time translation inlining, the `$localize.locale`
expression will now be replaced with a string literal containing the
current locale of the translations.
PR Close#33314
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
There are numerous approaches to downlevelling backticked
template strings to ES5.
This commit handles yet another one that Babel applies.
PR Close#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
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
