` 上的 `Foo` 实例是正确的查询结果了。由于查询结果并不依赖于运行时的值，所以在解析此查询之前，我们不必等待模板上的变更检测。因此，`ngOnInit` 中这些结果就已经可用了。
+
Let's say the query is the same, but the component template looks like this:
+假设查询不变，但组件模板改成了这样：
+
```
```
@@ -110,49 +172,85 @@ With that template, the query would be categorized as a dynamic query.
We would need to know the runtime value of `showing` before determining what the correct results are for the query.
As a result, change detection must run first, and results can only be made available in `ngAfterViewInit` or a setter for the query property.
+对于该模板，该查询将被归类为动态查询。我们需要知道 `showing` 在运行期间的值，以便确定该查询的正确结果应该是什么。因此，必须首先运行变更检测，其结果只能在 `ngAfterViewInit` 或该查询属性的 setter 中才能使用。
+
The effect of this implementation is that adding an `*ngIf` or `*ngFor` anywhere above a query match can change when that query's results become available.
+这种实现方式的效果是，在查询匹配的任何父级节点添加 `*ngIf` 或 `*ngFor` 会导致：当查询结果可用之后，其匹配结果也会发生变化。
+
Keep in mind that these categories only applied to `@ViewChild` and `@ContentChild` queries specifically.
`@ViewChildren` and `@ContentChildren` queries did not have a concept of static and dynamic, so they were always resolved as if they were "dynamic".
+请记住，这些类别只能用于 `@ViewChild` 和 `@ContentChild` 这两种查询。而 `@ViewChildren` 和 `@ContentChildren` 查询没有静态和动态的概念，它们总是“动态”解析。
+
This strategy of resolving queries at different times based on the location of potential query matches has caused a lot of confusion. Namely:
+这种策略会根据查询所在的位置，在不同的时机进行解析，这引起了很大的困惑。即：
+
* Sometimes query results are available in `ngOnInit`, but sometimes they aren't and it's not clear why (see [21800](https://github.com/angular/angular/issues/21800) or [19872](https://github.com/angular/angular/issues/19872)).
+ 有时查询结果在 `ngOnInit` 中可用，但有时则不可用，而且还不清楚为什么（参见 [21800](https://github.com/angular/angular/issues/21800) 或 [19872](https://github.com/angular/angular/issues/19872)）。
+
* `@ViewChild` queries are resolved at a different time from `@ViewChildren` queries, and `@ContentChild` queries are resolved at a different time from `@ContentChildren` queries.
If a user turns a `@ViewChild` query into a `@ViewChildren` query, their code can break suddenly because the timing has shifted.
+ `@ViewChild` 查询和 `@ViewChildren` 查询的解析时机不一样，而 `@ContentChild` 查询和 `@ContentChildren` 查询的解析时机也不一样。如果用户把 `@ViewChild` 查询换成 `@ViewChildren` 查询，那么他们的代码就会突然崩溃，因为其解析时机不同了。
+
* Code depending on a query result can suddenly stop working as soon as an `*ngIf` or an `*ngFor` is added to a template.
+ 一旦往模板中添加了 `*ngIf` 或 `*ngFor`，依赖于查询结果的代码就会突然停止工作。
+
* A `@ContentChild` query for the same component will resolve at different times in the lifecycle for each usage of the component.
This leads to buggy behavior where using a component with `*ngIf` is broken in subtle ways that aren't obvious to the component author.
+ 当每次使用该组件时，对同一个组件的 `@ContentChild` 查询却会在生命周期的不同时机进行解析。这导致了一些错误的行为，即：带 `*ngIf` 的组件会以一种对组件作者来说很隐晦的、微妙的方式被破坏。
+
In version 9, we plan to simplify the behavior so all queries resolve after change detection runs by default.
The location of query matches in the template cannot affect when the query result will become available and suddenly break your code, and the default behavior is always the same.
This makes the logic more consistent and predictable for users.
+在版本 9 中，我们准备简化这种行为，以便默认情况，每当运行变更检测之后，就会解析所有查询。
+模板中查询的位置不会再影响查询结果何时可用，也不会突然破坏你的代码，其默认行为总是一样的。这样，这种逻辑对于用户来说就更加一致、更可预测。
+
That said, if an application does need query results earlier (for example, the query result is needed to create an embedded view), it's possible to add the `{static: true}` flag to explicitly ask for static resolution.
With this flag, users can indicate that they only care about results that are statically available and the query results will be populated before `ngOnInit`.
+也就是说，如果一个应用程序确实需要更早拿到查询结果（例如，在创建嵌入式视图时需要这种查询结果），就可以添加 `{static: true}` 标志来明确要求静态解析。有了这个标志，用户就可以表明他们只关心那些静态可用的结果，并且在 `ngOnInit` 之前就会填上查询结果。
+
{@a view-children-and-content-children}
### Does this change affect `@ViewChildren` or `@ContentChildren` queries?
+### 这项变化是否会影响 `@ViewChildren` 或 `@ContentChildren` 查询？
+
No, this change only affects `@ViewChild` and `@ContentChild` queries specifically.
`@ViewChildren` and `@ContentChildren` queries are already "dynamic" by default and don't support static resolution.
+不，这项变化只会影响 `@ViewChild` 和 `@ContentChild` 查询。默认情况下，`@ViewChildren` 和 `@ContentChildren` 查询已经是“动态”的，并且不支持静态解析。
+
{@a why-specify-static-false}
### Why do I have to specify `{static: false}`? Isn't that the default?
+### 为什么我还要指定 `{static: false}`？这不是默认的吗？
+
The goal of this migration is to transition apps that aren't yet on version 9 to a query pattern that is compatible with version 9.
However, most applications use libraries, and it's likely that some of these libraries may not be upgraded to version 8 yet (and thus might not have the proper flags).
Since the application's version of Angular will be used for compilation, if we change the default, the behavior of queries in the library's components will change to the version 8 default and possibly break.
This way, an application's dependencies will behave the same way during the transition as they did in the previous version.
+本次迁移的目的是把现在的版本 9 之前的应用转换为兼容版本 9 的查询模式。然而，大多数应用都会用到库，而其中某些库可能还无法升级到版本 8（因而可能没有合适的标志值）。由于应用程序编译时会用到当前的 Angular 版本，如果我们修改了默认值，库里组件的查询行为就会变成版本 8 的这个默认值，这可能导致破坏性变更。而现在这种方式，应用程序的依赖项在转换过程中的行为就会与之前版本中的一样。
+
In Angular version 9 and later, it will be safe to remove any `{static: false}` flags and we will do this cleanup for you in a schematic.
+在 Angular 9 及更高版本中，删除任何 `{static: false}` 标志都是安全的，我们会在原理图中为你完成这个清理工作。
+
{@a libraries}
### Can I keep on using Angular libraries that haven’t yet updated to version 8 yet?
+### 我还可以继续使用尚未更新到版本 8 的 Angular 库吗？
+
Yes, absolutely!
Because we have not changed the default query behavior in version 8 (i.e. the compiler still chooses a timing if no flag is set), when your application runs with a library that has not updated to version 8, the library will run the same way it did in version 7.
This guarantees your app will work in version 8 even if libraries take longer to update their code.
+
+绝对没问题！
+因为我们没有改变版本 8 中的默认查询行为（比如编译器在没有设置任何标志的情况下仍然会自己选择一个合适的时机），所以当你的应用运行时，如果你的库没有更新到版本 8，该库的运行方式就和版本 7 中是一样的。这样就可以保证你的应用在版本 8 中仍然可以工作，不过这些库的开发者就需要花费更长的时间来修改代码了。