fix: translated the rest of i18n
This commit is contained in:
parent
160306833c
commit
ab47b12f52
|
@ -489,13 +489,15 @@ By default, the tool generates a translation file named **`messages.xlf`** in th
|
|||
|
||||
### 其它翻译格式
|
||||
|
||||
// TODO: Translate
|
||||
|
||||
Angular i18n tooling supports XLIFF 1.2 and XLIFF 2 as well as the
|
||||
<a href="http://cldr.unicode.org/development/development-process/design-proposals/xmb" >XML Message Bundle (XMB)</a>.
|
||||
|
||||
除了<a href="http://cldr.unicode.org/development/development-process/design-proposals/xmb" >XML消息捆(XMB)</a>格式外,Angular的i18n工具也同样支持 XLIFF 1.2和XLIFF 2 格式。
|
||||
|
||||
You can specify your choice of format _explicitly_ with the `--i18nFormat` flag as illustrated in these example commands
|
||||
|
||||
我们可以使用`--i18nFormat`来明确指定想用的格式,范例如下:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
./node_modules/.bin/ng-xi18n --i18nFormat=xlf --outFile=messages.xlf
|
||||
./node_modules/.bin/ng-xi18n --i18nFormat=xlf2 --outFile=messages.xliff2.xlf
|
||||
|
@ -504,15 +506,22 @@ You can specify your choice of format _explicitly_ with the `--i18nFormat` flag
|
|||
|
||||
The sample in _this_ guide sticks with the default _XLIFF 1.2_ format.
|
||||
|
||||
本章的范例默认使用 _XLIFF 1.2_ 格式。
|
||||
|
||||
{@a ng-xi18n-options}
|
||||
|
||||
### Other options
|
||||
|
||||
### 其它选项
|
||||
|
||||
You may have to specify additional options.
|
||||
For example, if the `tsconfig.json` TypeScript configuration
|
||||
file is located somewhere other than in the root folder,
|
||||
you must identify the path to it with the `-p` option:
|
||||
|
||||
我们还可能需要指定其它选项。
|
||||
比如,如果TypeScript的配置文件`tsconfig.json`位于其它地方而不是根目录,我们就要通过`-p`选项来明确指出它的路径。
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
./node_modules/.bin/ng-xi18n -p path/to/tsconfig.json
|
||||
./node_modules/.bin/ng-xi18n --i18nFormat=xmb -p path/to/tsconfig.json
|
||||
|
@ -522,9 +531,13 @@ you must identify the path to it with the `-p` option:
|
|||
|
||||
### Add an _npm_ script for convenience
|
||||
|
||||
### 添加`npm`便利脚本
|
||||
|
||||
Consider adding a convenience shortcut to the `scripts` section of the `package.json`
|
||||
to make the command easier to remember and run:
|
||||
|
||||
考虑在`package.json`的`scripts`区中添加一个便利脚本,来让命令更容易记忆和运行:
|
||||
|
||||
<code-example format='.' language='sh'>
|
||||
"scripts": {
|
||||
"i18n": "ng-xi18n",
|
||||
|
@ -534,6 +547,8 @@ to make the command easier to remember and run:
|
|||
|
||||
Now you can issue command variations such as these:
|
||||
|
||||
现在,我们就可以使用这些命令的变体形式了,比如:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
npm run i18n
|
||||
npm run i18n -- -p path/to/tsconfig.json
|
||||
|
@ -543,6 +558,8 @@ Now you can issue command variations such as these:
|
|||
Note the `--` flag before the options.
|
||||
It tells _npm_ to pass every flag thereafter to `ng-xi18n`.
|
||||
|
||||
注意选项前面的`--`标识。它告诉`npm`要把这个参数后面的每一个标识都透传给`ng-xi18n`。
|
||||
|
||||
{@a translate}
|
||||
|
||||
## Translate text messages
|
||||
|
@ -554,6 +571,7 @@ in the project root folder named `messages.xlf`.
|
|||
The next step is to translate the English language template
|
||||
text into the specific language translation
|
||||
files. The guide sample creates a Spanish translation file.
|
||||
|
||||
`ng-xi18n`命令在项目根目录生成一个名为`messages.xlf`的翻译源文件。
|
||||
下一步是将英文模板文本翻译到目标语言的翻译文件。
|
||||
本烹饪书创建了一个西班牙语翻译文件。
|
||||
|
@ -652,74 +670,119 @@ Change either factor and the `id` changes as well.
|
|||
|
||||
See the **[translation file maintenance discussion](#maintenance)**.
|
||||
|
||||
参见**[关于如何维护翻译结果文件的讨论](#maintenance)**。
|
||||
|
||||
This is why you should **[specify custom ids](#custom-id "Set a custom id")** and avoid tool generated ids.
|
||||
|
||||
这就是为什么我们应该**[指定自定义 id](#custom-id "Set a custom id")**,避免让工具自动生成id。
|
||||
|
||||
</div>
|
||||
|
||||
{@a translate-plural-select}
|
||||
|
||||
## Translate _plural_ and _select_
|
||||
|
||||
## 翻译*复数(plural)*和*选择(select)*
|
||||
|
||||
Translating _plural_ and _select_ messages is a little tricky.
|
||||
|
||||
翻译*复数*和*选择*类的消息有点棘手。
|
||||
|
||||
The `<source>` tag is empty for `plural` and `select` translation
|
||||
units, which makes them hard to correlate with the original template.
|
||||
The `XLIFF` format doesn't yet support the ICU rules.
|
||||
However, the `XMB` format does support the ICU rules.
|
||||
|
||||
对于复数(`plural`)和选择(`select`)类型的翻译单元来说,<source>`标签是空的,这让它们很难和原始模板关联起来。
|
||||
`XLIFF` 不支持这种 ICU 规则,但`XMB`格式却支持。
|
||||
|
||||
You'll just have to look for them in relation to other translation units that you recognize from elsewhere in the source template.
|
||||
In this example, you know the translation unit for the `select` must be just below the translation unit for the logo.
|
||||
|
||||
我们要根据从原始模板中其它地方识别出来的翻译单元来找到建立它和原始模板之间的关联。
|
||||
比如在这个例子中,我们知道`select`一定会出现在logo的翻译单元的紧下方。
|
||||
|
||||
{@a translate-plural}
|
||||
|
||||
### Translate _plural_
|
||||
|
||||
### 翻译*复数*
|
||||
|
||||
To translate a `plural`, translate its ICU format match values:
|
||||
|
||||
要翻译一个复数,就要翻译它的ICU格式中匹配的值:
|
||||
|
||||
<code-example path="i18n/src/locale/messages.es.xlf.html" region="translated-plural" title="src/locale/messages.es.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a translate-select}
|
||||
|
||||
### Translate _select_
|
||||
|
||||
### 翻译*选择*(select)
|
||||
|
||||
The `select` behaves a little differently. Here again is the ICU format message in the component template:
|
||||
|
||||
`select`的行为略有不同。我们仍然来看组件模板中的ICU格式的消息:
|
||||
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-select" title="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The extraction tool broke that into _two_ translation units.
|
||||
|
||||
提取工具会把它拆成*两个*翻译单元。
|
||||
|
||||
The first unit contains the text that was _outside_ the `select`.
|
||||
In place of the `select` is a placeholder, `<x id="ICU">`, that represents the `select` message.
|
||||
Translate the text and leave the placeholder where it is.
|
||||
|
||||
第一个单元包含`select`之外的文本。
|
||||
这里的`select`是一个占位符`<x id="ICU">`,用来表示`select`中的消息。
|
||||
翻译这段文本,并把占位符放在那里。
|
||||
|
||||
<code-example path="i18n/src/locale/messages.es.xlf.html" region="translate-select-1" title="src/locale/messages.es.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The second translation unit, immediately below the first one, contains the `select` message. Translate that.
|
||||
|
||||
第一个翻译单元的紧下方就是第二个翻译单元,包含`select`中的消息。翻译它。
|
||||
|
||||
<code-example path="i18n/src/locale/messages.es.xlf.html" region="translate-select-2" title="src/locale/messages.es.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here they are together, after translation:
|
||||
|
||||
在翻译之后,它们会放在一起:
|
||||
|
||||
<code-example path="i18n/src/locale/messages.es.xlf.html" region="translated-select" title="src/locale/messages.es.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Translate a nested expression
|
||||
|
||||
### 翻译嵌套的表达式
|
||||
|
||||
A nested expression is not different from the previous ones. As in the previous example, we have _two_ translation units.
|
||||
|
||||
嵌套的表达式和前一节没有什么不同。就像上一个例子中那样,我们有*两个*翻译单元。
|
||||
|
||||
The first one contains the text outside the nested expression:
|
||||
|
||||
第一个包含嵌套表达式外部的文本:
|
||||
|
||||
<code-example path="i18n/src/locale/messages.es.xlf.html" region="translate-nested-1" title="src/locale/messages.es.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The second unit contains the complete nested expression:
|
||||
|
||||
第二个包含完整的嵌套表达式:
|
||||
|
||||
<code-example path="i18n/src/locale/messages.es.xlf.html" region="translate-nested-2" title="src/locale/messages.es.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
And both together:
|
||||
|
||||
放在一起时:
|
||||
|
||||
<code-example path="i18n/src/locale/messages.es.xlf.html" region="translate-nested" title="src/locale/messages.es.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
@ -728,6 +791,8 @@ And both together:
|
|||
The entire template translation is complete. It's
|
||||
time to incorporate that translation into the application.
|
||||
|
||||
整个模板的翻译就完成了。现在就该把翻译结果放回到应用程序中了。
|
||||
|
||||
<a id='app-pre-translation'></a>
|
||||
|
||||
### The app before translation
|
||||
|
@ -1058,25 +1123,44 @@ Windows用户可能需要双引号这个命令:
|
|||
|
||||
### Report missing translations
|
||||
|
||||
### 汇报缺失的翻译
|
||||
|
||||
If you forgot to provide a translation, the build will succeed with a warning that you might easily overlook.
|
||||
You can configure the Angular compiler for different "missing translation" behaviors:
|
||||
|
||||
如果你忘了提供翻译,构建工具会给出警告,以便你更容易发现它们。
|
||||
我们可以把 Angular 编译器配置为发现"缺少翻译"时采取不同的行动:
|
||||
|
||||
* Error
|
||||
|
||||
报错
|
||||
|
||||
* Warning (default)
|
||||
|
||||
警告(默认值)
|
||||
|
||||
* Ignore
|
||||
|
||||
忽略
|
||||
|
||||
To change the behavior in JIT, you can use the following configuration:
|
||||
|
||||
要在 JIT 编译器中改变这种行为,我们可以使用下列配置:
|
||||
|
||||
<code-example language="typescript">
|
||||
{ provide: CompilerConfig, useValue: new CompilerConfig({ missingTranslation: MissingTranslationStrategy.Error }) }
|
||||
</code-example>
|
||||
|
||||
A good place to use it is the translation providers:
|
||||
|
||||
使用它的一个好地方是在 "翻译服务提供商(provider)" 中:
|
||||
|
||||
<code-example path="i18n/src/app/i18n-providers.ts" region="missing-translation" title="src/app/i18n-providers.ts"></code-example>
|
||||
|
||||
To change the behavior in AOT, add the `--missingTranslation` flag to the compilation command:
|
||||
|
||||
要在 AOT 编译器中改变这种行为,可以在编译命令行中添加 `--missingTranslation` 标志:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
./node_modules/.bin/ngc --i18nFile=./locale/messages.es.xlf --locale=es --i18nFormat=xlf --missingTranslation=error
|
||||
</code-example>
|
||||
|
@ -1085,24 +1169,39 @@ To change the behavior in AOT, add the `--missingTranslation` flag to the compil
|
|||
|
||||
## File maintenance and _id_ changes
|
||||
|
||||
## 文件维护与`id`的改变
|
||||
|
||||
As the application evolves, you will change the _i18n_ markup
|
||||
and re-run the `ng-xi18n` extraction tool many times.
|
||||
The _new_ markup that you add is not a problem.
|
||||
But the `id` _can be a serious problem!_
|
||||
|
||||
随着应用的成长,我们会修改 `i18n` 的页面脚本,并且多次重新运行 `ng-xi18n` 提取工具。
|
||||
你*新增的*脚本毫无问题,但是原有脚本的 `id` *可能会面临一系列问题!*
|
||||
|
||||
If the `id` is generated by the tool, _most_ changes to _existing_ markup
|
||||
cause the tool to generate a _new_ `id` for the affected translation unit.
|
||||
|
||||
如果`id`是由工具生成的,*大部分*对*现有*脚本的改动会导致工具重新生成*新的* `id` ,从而影响到翻译单元。
|
||||
|
||||
After an `id` changes, the translation files are no longer in sync.
|
||||
Because of that, you get some warning messages during re-compilation.
|
||||
The warning messages identify that some translations are missing, but they don't tell you which
|
||||
old `ids` are no longer valid.
|
||||
|
||||
在一个`id`变化之后,翻译结果文件将不再同步。
|
||||
因此,我们会在重新编译的时候收到一些警告信息。
|
||||
这些警告信息标识出了哪些翻译结果被丢了,但却不会告诉我们哪些原有的`id`失效了。
|
||||
|
||||
If you use a [custom id](#custom-id "Set a custom id"),
|
||||
the tooling preserves the custom `id` as you make changes to the corresponding translation unit. **Use custom _ids_ unless you have a very good reason to do otherwise.**
|
||||
|
||||
如果我们使用[自定义 id](#custom-id "Set a custom id"),当你修改相应的翻译单元时,工具就会保留这些自定义`id`。**除非有特别好的理由,否则应该总是使用自定义`id`**。
|
||||
|
||||
Whether you use generated or custom `ids`, **always commit all translation message files to source control**,
|
||||
especially the English source `messages.xlf`.
|
||||
The difference between the old and the new `messages.xlf` file
|
||||
will help you find and update `ids` and other changes across your translation files.
|
||||
|
||||
无论我们是所有自动生成的id还是自定义id,**都总是要把所有的翻译结果文件提交到源码控制系统中**,特别是英语的源文件`messages.xlf`。
|
||||
比较新旧`messages.xlf`文件之间的不同,可以帮助你在多个翻译结果文件之间发现`id`的变化,以及其它更改。
|
||||
|
|
Loading…
Reference in New Issue