From 5e069b42a3f2c8c90cef323a80b6ab12cf80e1c0 Mon Sep 17 00:00:00 2001
From: Suguru Inatomi <suguru.inatomi@gmail.com>
Date: Sat, 20 Jul 2024 13:37:01 +0900
Subject: [PATCH 1/3] chore: copy file

---
 .../di/hierarchical-dependency-injection.md   | 1180 +++++++++++++++++
 1 file changed, 1180 insertions(+)
 create mode 100644 adev-ja/src/content/guide/di/hierarchical-dependency-injection.md

diff --git a/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
new file mode 100644
index 0000000000..75465edfb4
--- /dev/null
+++ b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
@@ -0,0 +1,1180 @@
+# Hierarchical injectors
+
+Injectors in Angular have rules that you can leverage to achieve the desired visibility of injectables in your applications.
+By understanding these rules, you can determine whether to declare a provider at the application level, in a Component, or in a Directive.
+
+The applications you build with Angular can become quite large, and one way to manage this complexity is to split up the application into a well-defined tree of components.
+
+There can be sections of your page that work in a completely independent way than the rest of the application, with its own local copies of the services and other dependencies that it needs.
+Some of the services that these sections of the application use might be shared with other parts of the application, or with parent components that are further up in the component tree, while other dependencies are meant to be private.
+
+With hierarchical dependency injection, you can isolate sections of the application and give them their own private dependencies not shared with the rest of the application, or have parent components share certain dependencies with its child components only but not with the rest of the component tree, and so on. Hierarchical dependency injection enables you to share dependencies between different parts of the application only when and if you need to.
+
+## Types of injector hierarchies
+
+Angular has two injector hierarchies:
+
+| Injector hierarchies        | Details |
+|:---                         |:---     |
+| `EnvironmentInjector` hierarchy | Configure an `ElementInjector` in this hierarchy using `@Injectable()` or `providers` array in `ApplicationConfig`. |
+| `ElementInjector` hierarchy | Created implicitly at each DOM element. An `ElementInjector` is empty by default unless you configure it in the `providers` property on `@Directive()` or `@Component()`. |
+
+<docs-callout title="NgModule Based Applications">
+For `NgModule` based applications, you can provide dependencies with the `ModuleInjector` hierarchy using an `@NgModule()` or `@Injectable()` annotation.
+</docs-callout>
+
+### `EnvironmentInjector`
+
+The `EnvironmentInjector` can be configured in one of two ways by using:
+
+* The `@Injectable()` `providedIn` property to refer to `root` or `platform`
+* The `ApplicationConfig` `providers` array
+
+<docs-callout title="Tree-shaking and @Injectable()">
+
+Using the `@Injectable()` `providedIn` property is preferable to using the `ApplicationConfig` `providers` array. With `@Injectable()` `providedIn`, optimization tools can perform tree-shaking, which removes services that your application isn't using. This results in smaller bundle sizes.
+
+Tree-shaking is especially useful for a library because the application which uses the library may not have a need to inject it.
+
+</docs-callout>
+
+`EnvironmentInjector` is configured by the `ApplicationConfig.providers`.
+
+Provide services using `providedIn` of `@Injectable()` as follows:
+
+<docs-code language="typescript" highlight="[4]">
+import { Injectable } from '@angular/core';
+
+@Injectable({
+  providedIn: 'root'  // <--provides this service in the root EnvironmentInjector
+})
+export class ItemService {
+  name = 'telephone';
+}
+
+</docs-code>
+
+The `@Injectable()` decorator identifies a service class.
+The `providedIn` property configures a specific `EnvironmentInjector`, here `root`, which makes the service available in the `root` `EnvironmentInjector`.
+
+### ModuleInjector
+
+In the case of `NgModule` based applications, the ModuleInjector can be configured in one of two ways by using:
+
+* The `@Injectable()` `providedIn` property to refer to `root` or `platform`
+* The `@NgModule()` `providers` array
+
+`ModuleInjector` is configured by the `@NgModule.providers` and `NgModule.imports` property. `ModuleInjector` is a flattening of all the providers arrays that can be reached by following the `NgModule.imports` recursively.
+
+Child `ModuleInjector` hierarchies are created when lazy loading other `@NgModules`.
+
+### Platform injector
+
+There are two more injectors above `root`, an additional `EnvironmentInjector` and `NullInjector()`.
+
+Consider how Angular bootstraps the application with the following in `main.ts`:
+
+<docs-code language="javascript">
+bootstrapApplication(AppComponent, appConfig);
+</docs-code>
+
+The `bootstrapApplication()` method creates a child injector of the platform injector which is configured by the `ApplicationConfig` instance.
+This is the `root` `EnvironmentInjector`.
+
+The `platformBrowserDynamic()` method creates an injector configured by a `PlatformModule`, which contains platform-specific dependencies.
+This allows multiple applications to share a platform configuration.
+For example, a browser has only one URL bar, no matter how many applications you have running.
+You can configure additional platform-specific providers at the platform level by supplying `extraProviders` using the `platformBrowser()` function.
+
+The next parent injector in the hierarchy is the `NullInjector()`, which is the top of the tree.
+If you've gone so far up the tree that you are looking for a service in the `NullInjector()`, you'll get an error unless you've used `@Optional()` because ultimately, everything ends at the `NullInjector()` and it returns an error or, in the case of `@Optional()`, `null`.
+For more information on `@Optional()`, see the [`@Optional()` section](#optional) of this guide.
+
+The following diagram represents the relationship between the `root` `ModuleInjector` and its parent injectors as the previous paragraphs describe.
+
+```mermaid
+stateDiagram-v2
+    elementInjector: EnvironmentInjector\n(configured by Angular)\nhas special things like DomSanitizer => providedIn 'platform'
+    rootInjector: root EnvironmentInjector\n(configured by AppConfig)\nhas things for your app => bootstrapApplication(..., AppConfig)
+    nullInjector: NullInjector\nalways throws an error unless\nyou use @Optional()
+
+    direction BT
+    rootInjector --> elementInjector
+    elementInjector --> nullInjector
+```
+
+While the name `root` is a special alias, other `EnvironmentInjector` hierarchies don't have aliases.
+You have the option to create `EnvironmentInjector` hierarchies whenever a dynamically loaded component is created, such as with the Router, which will create child `EnvironmentInjector` hierarchies.
+
+All requests forward up to the root injector, whether you configured it with the `ApplicationConfig` instance passed to the `bootstrapApplication()` method, or registered all providers with `root` in their own services.
+
+<docs-callout title="@Injectable() vs. ApplicationConfig">
+
+If you configure an app-wide provider in the `ApplicationConfig` of `bootstrapApplication`, it overrides one configured for `root` in the `@Injectable()` metadata.
+You can do this to configure a non-default provider of a service that is shared with multiple applications.
+
+Here is an example of the case where the component router configuration includes a non-default [location strategy](guide/routing#location-strategy) by listing its provider in the `providers` list of the `ApplicationConfig`.
+
+```ts
+providers: [
+  { provide: LocationStrategy, useClass: HashLocationStrategy }
+]
+```
+
+For `NgModule` based applications, configure app-wide providers in the `AppModule` `providers`.
+
+</docs-callout>
+
+### `ElementInjector`
+
+Angular creates `ElementInjector` hierarchies implicitly for each DOM element.
+
+Providing a service in the `@Component()` decorator using its `providers` or `viewProviders` property configures an `ElementInjector`.
+For example, the following `TestComponent` configures the `ElementInjector` by providing the service as follows:
+
+<docs-code language="typescript" highlight="[3]">
+@Component({
+  …
+  providers: [{ provide: ItemService, useValue: { name: 'lamp' } }]
+})
+export class TestComponent
+</docs-code>
+
+HELPFUL: See the [resolution rules](#resolution-rules) section to understand the relationship between the `EnvironmentInjector` tree, the `ModuleInjector` and the `ElementInjector` tree.
+
+When you provide services in a component, that service is available by way of the `ElementInjector` at that component instance.
+It may also be visible at child component/directives based on visibility rules described in the [resolution rules](#resolution-rules) section.
+
+When the component instance is destroyed, so is that service instance.
+
+#### `@Directive()` and `@Component()`
+
+A component is a special type of directive, which means that just as `@Directive()` has a `providers` property, `@Component()` does too.
+This means that directives as well as components can configure providers, using the `providers` property.
+When you configure a provider for a component or directive using the `providers` property, that provider belongs to the `ElementInjector` of that component or directive.
+Components and directives on the same element share an injector.
+
+## Resolution rules
+
+When resolving a token for a component/directive, Angular resolves it in two phases:
+
+1. Against its parents in the `ElementInjector` hierarchy.
+2. Against its parents in the `EnvironmentInjector` hierarchy.
+
+When a component declares a dependency, Angular tries to satisfy that dependency with its own `ElementInjector`.
+If the component's injector lacks the provider, it passes the request up to its parent component's `ElementInjector`.
+
+The requests keep forwarding up until Angular finds an injector that can handle the request or runs out of ancestor `ElementInjector` hierarchies.
+
+If Angular doesn't find the provider in any `ElementInjector` hierarchies, it goes back to the element where the request originated and looks in the `EnvironmentInjector` hierarchy.
+If Angular still doesn't find the provider, it throws an error.
+
+If you have registered a provider for the same DI token at different levels, the first one Angular encounters is the one it uses to resolve the dependency.
+If, for example, a provider is registered locally in the component that needs a service,
+Angular doesn't look for another provider of the same service.
+
+HELPFUL: For `NgModule` based applications, Angular will search the `ModuleInjector` hierarchy if it cannot find a provider in the `ElementInjector` hierarchies.
+
+## Resolution modifiers
+
+Angular's resolution behavior can be modified with `@Optional()`, `@Self()`, `@SkipSelf()` and `@Host()`.
+Import each of them from `@angular/core` and use each in the component class constructor or in the `inject` configuration when you inject your service.
+
+### Types of modifiers
+
+Resolution modifiers fall into three categories:
+
+* What to do if Angular doesn't find what you're looking for, that is `@Optional()`
+* Where to start looking, that is `@SkipSelf()`
+* Where to stop looking, `@Host()` and `@Self()`
+
+By default, Angular always starts at the current `Injector` and keeps searching all the way up.
+Modifiers allow you to change the starting, or _self_, location and the ending location.
+
+Additionally, you can combine all of the modifiers except:
+
+* `@Host()` and `@Self()`
+* `@SkipSelf()` and `@Self()`.
+
+### `@Optional()`
+
+`@Optional()` allows Angular to consider a service you inject to be optional.
+This way, if it can't be resolved at runtime, Angular resolves the service as `null`, rather than throwing an error.
+In the following example, the service, `OptionalService`, isn't provided in the service, `ApplicationConfig`, `@NgModule()`, or component class, so it isn't available anywhere in the app.
+
+<docs-code header="src/app/optional/optional.component.ts" language="typescript">
+export class OptionalComponent {
+  constructor(@Optional() public optional?: OptionalService) {}
+}
+</docs-code>
+
+### `@Self()`
+
+Use `@Self()` so that Angular will only look at the `ElementInjector` for the current component or directive.
+
+A good use case for `@Self()` is to inject a service but only if it is available on the current host element.
+To avoid errors in this situation, combine `@Self()` with `@Optional()`.
+
+For example, in the following `SelfComponent`, notice the injected `LeafService` in the constructor.
+
+<docs-code header="src/app/self-no-data/self-no-data.component.ts" language="typescript"
+           highlight="[7]">
+@Component({
+  selector: 'app-self-no-data',
+  templateUrl: './self-no-data.component.html',
+  styleUrls: ['./self-no-data.component.css']
+})
+export class SelfNoDataComponent {
+  constructor(@Self() @Optional() public leaf?: LeafService) { }
+}
+</docs-code>
+
+In this example, there is a parent provider and injecting the service will return the value, however, injecting the service with `@Self()` and `@Optional()` will return `null` because `@Self()` tells the injector to stop searching in the current host element.
+
+Another example shows the component class with a provider for `FlowerService`.
+In this case, the injector looks no further than the current `ElementInjector` because it finds the `FlowerService` and returns the tulip <code>&#x1F337;</code>.
+
+<docs-code header="src/app/self/self.component.ts" path="adev/src/content/examples/resolution-modifiers/src/app/self/self.component.ts" visibleRegion="self-component"/>
+
+### `@SkipSelf()`
+
+`@SkipSelf()` is the opposite of `@Self()`.
+With `@SkipSelf()`, Angular starts its search for a service in the parent `ElementInjector`, rather than in the current one.
+So if the parent `ElementInjector` were using the fern <code>&#x1F33F;</code> value for `emoji`, but you had maple leaf <code>&#x1F341;</code> in the component's `providers` array, Angular would ignore maple leaf <code>&#x1F341;</code> and use fern <code>&#x1F33F;</code>.
+
+To see this in code, assume that the following value for `emoji` is what the parent component were using, as in this service:
+
+<docs-code header="src/app/leaf.service.ts" language="typescript">
+export class LeafService {
+  emoji = '🌿';
+}
+</docs-code>
+
+Imagine that in the child component, you had a different value, maple leaf <code>&#x1F341;</code> but you wanted to use the parent's value instead.
+This is when you'd use `@SkipSelf()`:
+
+<docs-code header="src/app/skipself/skipself.component.ts" language="typescript"
+           highlight="[[6],[10]]">
+@Component({
+  selector: 'app-skipself',
+  templateUrl: './skipself.component.html',
+  styleUrls: ['./skipself.component.css'],
+  // Angular would ignore this LeafService instance
+  providers: [{ provide: LeafService, useValue: { emoji: '🍁' } }]
+})
+export class SkipselfComponent {
+  // Use @SkipSelf() in the constructor
+  constructor(@SkipSelf() public leaf: LeafService) { }
+}
+</docs-code>
+
+In this case, the value you'd get for `emoji` would be fern <code>&#x1F33F;</code>, not maple leaf <code>&#x1F341;</code>.
+
+#### `@SkipSelf()` with `@Optional()`
+
+Use `@SkipSelf()` with `@Optional()` to prevent an error if the value is `null`.
+
+In the following example, the `Person` service is injected in the constructor.
+`@SkipSelf()` tells Angular to skip the current injector and `@Optional()` will prevent an error should the `Person` service be `null`.
+
+<docs-code language="typescript">
+class Person {
+  constructor(@Optional() @SkipSelf() parent?: Person) {}
+}
+</docs-code>
+
+### `@Host()`
+
+<!-- TODO: Remove ambiguity between @Host and @Self. -->
+
+`@Host()` lets you designate a component as the last stop in the injector tree when searching for providers.
+
+Even if there is a service instance further up the tree, Angular won't continue looking.
+Use `@Host()` as follows:
+
+<docs-code header="src/app/host/host.component.ts" language="typescript"
+           highlight="[[6],[10]]">
+@Component({
+  selector: 'app-host',
+  templateUrl: './host.component.html',
+  styleUrls: ['./host.component.css'],
+  //  provide the service
+  providers: [{ provide: FlowerService, useValue: { emoji: '🌷' } }]
+})
+export class HostComponent {
+  // use @Host() in the constructor when injecting the service
+  constructor(@Host() @Optional() public flower?: FlowerService) { }
+}
+</docs-code>
+
+Since `HostComponent` has `@Host()` in its constructor, no matter what the parent of `HostComponent` might have as a `flower.emoji` value, the `HostComponent` will use tulip <code>&#x1F337;</code>.
+
+## Logical structure of the template
+
+When you provide services in the component class, services are visible within the `ElementInjector` tree relative to where and how you provide those services.
+
+Understanding the underlying logical structure of the Angular template will give you a foundation for configuring services and in turn control their visibility.
+
+Components are used in your templates, as in the following example:
+
+<docs-code language="html">
+<app-root>
+  <app-child></app-child>;
+</app-root>
+</docs-code>
+
+HELPFUL: Usually, you declare the components and their templates in separate files.
+For the purposes of understanding how the injection system works, it is useful to look at them from the point of view of a combined logical tree.
+The term _logical_ distinguishes it from the render tree, which is your application's DOM tree.
+To mark the locations of where the component templates are located, this guide uses the `<#VIEW>` pseudo-element, which doesn't actually exist in the render tree and is present for mental model purposes only.
+
+The following is an example of how the `<app-root>` and `<app-child>` view trees are combined into a single logical tree:
+
+<docs-code language="html">
+<app-root>
+  <#VIEW>
+    <app-child>
+     <#VIEW>
+       …content goes here…
+     </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+</docs-code>
+
+Understanding the idea of the `<#VIEW>` demarcation is especially significant when you configure services in the component class.
+
+## Example: Providing services in `@Component()`
+
+How you provide services using a `@Component()` (or `@Directive()`) decorator determines their visibility.
+The following sections demonstrate `providers` and `viewProviders` along with ways to modify service visibility with `@SkipSelf()` and `@Host()`.
+
+A component class can provide services in two ways:
+
+| Arrays                       | Details |
+|:---                          |:---     |
+| With a `providers` array     | `@Component({ providers: [SomeService] })`     |
+| With a `viewProviders` array | `@Component({ viewProviders: [SomeService] })` |
+
+In the examples below, you will see the logical tree of an Angular application.
+To illustrate how the injector works in the context of templates, the logical tree will represent the HTML structure of the application.
+For example, the logical tree will show that `<child-component>` is a direct children of `<parent-component>`.
+
+In the logical tree, you will see special attributes: `@Provide`, `@Inject`, and `@ApplicationConfig`.
+These aren't real attributes but are here to demonstrate what is going on under the hood.
+
+| Angular service attribute                                                                                          | Details |
+|:---                                                                                                                |:---     |
+| `@Inject(Token)=>Value`     | If `Token` is injected at this location in the logical tree, its value would be `Value`.     |
+| `@Provide(Token=Value)`     | Indicates that `Token` is provided with `Value` at this location in the logical tree.        |
+| `@ApplicationConfig` | Demonstrates that a fallback `EnvironmentInjector` should be used at this location.          |
+
+### Example app structure
+
+The example application has a `FlowerService` provided in `root` with an `emoji` value of red hibiscus <code>&#x1F33A;</code>.
+
+<docs-code header="src/app/flower.service.ts" language="typescript">
+@Injectable({
+  providedIn: 'root'
+})
+export class FlowerService {
+  emoji = '🌺';
+}
+</docs-code>
+
+Consider an application with only an `AppComponent` and a `ChildComponent`.
+The most basic rendered view would look like nested HTML elements such as the following:
+
+<docs-code language="html">
+
+<app-root> <!-- AppComponent selector -->
+  <app-child> <!-- ChildComponent selector -->
+  </app-child>
+</app-root>
+
+</docs-code>
+
+However, behind the scenes, Angular uses a logical view representation as follows when resolving injection requests:
+
+<docs-code language="html">
+<app-root> <!-- AppComponent selector -->
+  <#VIEW>
+    <app-child> <!-- ChildComponent selector -->
+      <#VIEW>
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+</docs-code>
+
+The `<#VIEW>` here represents an instance of a template.
+Notice that each component has its own `<#VIEW>`.
+
+Knowledge of this structure can inform how you provide and inject your services, and give you complete control of service visibility.
+
+Now, consider that `<app-root>` injects the `FlowerService`:
+
+<docs-code header="src/app/app.component.ts" language="typescript">
+export class AppComponent  {
+  constructor(public flower: FlowerService) {}
+}
+</docs-code>
+
+Add a binding to the `<app-root>` template to visualize the result:
+
+<docs-code header="src/app/app.component.html" language="html">
+<p>Emoji from FlowerService: {{flower.emoji}}</p>
+</docs-code>
+
+The output in the view would be:
+
+<docs-code language="shell">
+Emoji from FlowerService: &#x1F33A;
+</docs-code>
+
+In the logical tree, this would be represented as follows:
+
+<docs-code language="html" highlight="[[1],[2],[4]]">
+<app-root @ApplicationConfig
+        @Inject(FlowerService) flower=>"&#x1F33A;">
+  <#VIEW>
+    <p>Emoji from FlowerService: {{flower.emoji}} (&#x1F33A;)</p>
+    <app-child>
+      <#VIEW>
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+When `<app-root>` requests the `FlowerService`, it is the injector's job to resolve the `FlowerService` token.
+The resolution of the token happens in two phases:
+
+1. The injector determines the starting location in the logical tree and an ending location of the search.
+    The injector begins with the starting location and looks for the token at each view level in the logical tree.
+    If the token is found it is returned.
+
+1. If the token is not found, the injector looks for the closest parent `EnvironmentInjector` to delegate the request to.
+
+In the example case, the constraints are:
+
+1. Start with `<#VIEW>` belonging to `<app-root>` and end with `<app-root>`.
+
+    * Normally the starting point for search is at the point of injection.
+        However, in this case `<app-root>` is a component. `@Component`s are special in that they also include their own `viewProviders`, which is why the search starts at `<#VIEW>` belonging to `<app-root>`.
+        This would not be the case for a directive matched at the same location.
+    * The ending location happens to be the same as the component itself, because it is the topmost component in this application.
+
+1. The `ElementInjector` provided by the `ApplicationConfig` acts as the fallback injector when the injection token can't be found in the `ElementInjector` hierarchies.
+
+### Using the `providers` array
+
+Now, in the `ChildComponent` class, add a provider for `FlowerService` to demonstrate more complex resolution rules in the upcoming sections:
+
+<docs-code header="src/app/child.component.ts" language="typescript"
+           highlight="[[5,6],[10]]">
+@Component({
+  selector: 'app-child',
+  templateUrl: './child.component.html',
+  styleUrls: ['./child.component.css'],
+  // use the providers array to provide a service
+  providers: [{ provide: FlowerService, useValue: { emoji: '🌻' } }]
+})
+export class ChildComponent {
+  // inject the service
+  constructor( public flower: FlowerService) { }
+}
+</docs-code>
+
+Now that the `FlowerService` is provided in the `@Component()` decorator, when the `<app-child>` requests the service, the injector has only to look as far as the `ElementInjector` in the `<app-child>`.
+It won't have to continue the search any further through the injector tree.
+
+The next step is to add a binding to the `ChildComponent` template.
+
+<docs-code header="src/app/child.component.html" language="html">
+<p>Emoji from FlowerService: {{flower.emoji}}</p>
+</docs-code>
+
+To render the new values, add `<app-child>` to the bottom of the `AppComponent` template so the view also displays the sunflower:
+
+<docs-code language="shell">
+Child Component
+Emoji from FlowerService: &#x1F33B;
+</docs-code>
+
+In the logical tree, this is represented as follows:
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+        @Inject(FlowerService) flower=>"&#x1F33A;">
+  <#VIEW>
+    <p>Emoji from FlowerService: {{flower.emoji}} (&#x1F33A;)</p>
+    <app-child @Provide(FlowerService="&#x1F33B;")
+               @Inject(FlowerService)=>"&#x1F33B;"> <!-- search ends here -->
+      <#VIEW> <!-- search starts here -->
+        <h2>Child Component</h2>
+        <p>Emoji from FlowerService: {{flower.emoji}} (&#x1F33B;)</p>
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+When `<app-child>` requests the `FlowerService`, the injector begins its search at the `<#VIEW>` belonging to `<app-child>` \(`<#VIEW>` is included because it is injected from `@Component()`\) and ends with `<app-child>`.
+In this case, the `FlowerService` is resolved in the `providers` array with sunflower <code>&#x1F33B;</code> of the `<app-child>`.
+The injector doesn't have to look any further in the injector tree.
+It stops as soon as it finds the `FlowerService` and never sees the red hibiscus <code>&#x1F33A;</code>.
+
+### Using the `viewProviders` array
+
+Use the `viewProviders` array as another way to provide services in the `@Component()` decorator.
+Using `viewProviders` makes services visible in the `<#VIEW>`.
+
+HELPFUL: The steps are the same as using the `providers` array, with the exception of using the `viewProviders` array instead.
+
+For step-by-step instructions, continue with this section.
+If you can set it up on your own, skip ahead to [Modifying service availability](#visibility-of-provided-tokens).
+
+For demonstration, we are building an `AnimalService` to demonstrate `viewProviders`.
+First, create an `AnimalService` with an `emoji` property of whale <code>&#x1F433;</code>:
+
+<docs-code header="src/app/animal.service.ts" language="typescript">
+import { Injectable } from '@angular/core';
+
+@Injectable({
+  providedIn: 'root'
+})
+export class AnimalService {
+  emoji = '🐳';
+}
+</docs-code>
+
+Following the same pattern as with the `FlowerService`, inject the `AnimalService` in the `AppComponent` class:
+
+<docs-code header="src/app/app.component.ts" language="typescript" highlight="[4]">
+export class AppComponent {
+  constructor(
+    public flower: FlowerService,
+    public animal: AnimalService) {}
+}
+</docs-code>
+
+HELPFUL: You can leave all the `FlowerService` related code in place as it will allow a comparison with the `AnimalService`.
+
+Add a `viewProviders` array and inject the `AnimalService` in the `<app-child>` class, too, but give `emoji` a different value.
+Here, it has a value of dog <code>&#x1F436;</code>.
+
+<docs-code header="src/app/child.component.ts" language="typescript"
+           highlight="[[7],[11]]">
+@Component({
+  selector: 'app-child',
+  templateUrl: './child.component.html',
+  styleUrls: ['./child.component.css'],
+  // provide services
+  providers: [{ provide: FlowerService, useValue: { emoji: '🌻' } }],
+  viewProviders: [{ provide: AnimalService, useValue: { emoji: '🐶' } }]
+})
+export class ChildComponent {
+  // inject service
+  constructor( public flower: FlowerService, public animal: AnimalService) { }
+...
+}
+</docs-code>
+
+Add bindings to the `ChildComponent` and the `AppComponent` templates.
+In the `ChildComponent` template, add the following binding:
+
+<docs-code header="src/app/child.component.html" language="html">
+<p>Emoji from AnimalService: {{animal.emoji}}</p>
+</docs-code>
+
+Additionally, add the same to the `AppComponent` template:
+
+<docs-code header="src/app/app.component.html" language="html">
+<p>Emoji from AnimalService: {{animal.emoji}}</p>s
+</docs-code>
+
+Now you should see both values in the browser:
+
+<docs-code hideCopy language="shell">
+
+AppComponent
+Emoji from AnimalService: &#x1F433;
+
+Child Component
+Emoji from AnimalService: &#x1F436;
+
+</docs-code>
+
+The logic tree for this example of `viewProviders` is as follows:
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+         @Inject(AnimalService) animal=>"&#x1F433;">
+  <#VIEW>
+    <app-child>
+      <#VIEW @Provide(AnimalService="&#x1F436;")
+            @Inject(AnimalService=>"&#x1F436;")>
+       <!-- ^^using viewProviders means AnimalService is available in <#VIEW>-->
+       <p>Emoji from AnimalService: {{animal.emoji}} (&#x1F436;)</p>
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+Just as with the `FlowerService` example, the `AnimalService` is provided in the `<app-child>` `@Component()` decorator.
+This means that since the injector first looks in the `ElementInjector` of the component, it finds the `AnimalService` value of dog <code>&#x1F436;</code>.
+It doesn't need to continue searching the `ElementInjector` tree, nor does it need to search the `ModuleInjector`.
+
+### `providers` vs. `viewProviders`
+
+The `viewProviders` field is conceptually similar to `providers`, but there is one notable difference.
+Configured providers in `viewProviders` are not visible to projected content that ends up as a logical children of the component.
+
+To see the difference between using `providers` and `viewProviders`, add another component to the example and call it `InspectorComponent`.
+`InspectorComponent` will be a child of the `ChildComponent`.
+In `inspector.component.ts`, inject the `FlowerService` and `AnimalService` in the constructor:
+
+<docs-code header="src/app/inspector/inspector.component.ts" language="typescript">
+export class InspectorComponent {
+  constructor(public flower: FlowerService, public animal: AnimalService) { }
+}
+</docs-code>
+
+You do not need a `providers` or `viewProviders` array.
+Next, in `inspector.component.html`, add the same markup from previous components:
+
+<docs-code header="src/app/inspector/inspector.component.html" language="html">
+<p>Emoji from FlowerService: {{flower.emoji}}</p>
+<p>Emoji from AnimalService: {{animal.emoji}}</p>
+</docs-code>
+
+Remember to add the `InspectorComponent` to the `ChildComponent` `imports` array.
+
+<docs-code header="src/app/child/child.component.ts" language="typescript"
+           highlight="[3]">
+@Component({
+  ...
+  imports: [InspectorComponent]
+})
+
+</docs-code>
+
+Next, add the following to `child.component.html`:
+
+<docs-code header="src/app/child/child.component.html" language="html"
+           highlight="[3,9]">
+...
+
+<div class="container">
+  <h3>Content projection</h3>
+  <ng-content></ng-content>
+</div>
+<h3>Inside the view</h3>
+
+<app-inspector></app-inspector>
+</docs-code>
+
+`<ng-content>` allows you to project content, and `<app-inspector>` inside the `ChildComponent` template makes the `InspectorComponent` a child component of `ChildComponent`.
+
+Next, add the following to `app.component.html` to take advantage of content projection.
+
+<docs-code header="src/app/app.component.html" language="html" highlight="[2]">
+<app-child>
+  <app-inspector></app-inspector>
+</app-child>
+</docs-code>
+
+The browser now renders the following, omitting the previous examples for brevity:
+
+<docs-code hideCopy language="shell">
+...
+Content projection
+
+Emoji from FlowerService: &#x1F33B;
+Emoji from AnimalService: &#x1F433;
+
+Emoji from FlowerService: &#x1F33B;
+Emoji from AnimalService: &#x1F436;
+
+</docs-code>
+
+These four bindings demonstrate the difference between `providers` and `viewProviders`.
+Remember that the dog emoji <code>&#x1F436;</code> is declared inside the `<#VIEW>` of `ChildComponent` and isn't visible to the projected content.
+Instead, the projected content sees the whale <code>&#x1F433;</code>.
+
+However, in the next output section though, the `InspectorComponent` is an actual child component of `ChildComponent`, `InspectorComponent` is inside the `<#VIEW>`, so when it asks for the `AnimalService`, it sees the dog <code>&#x1F436;</code>.
+
+The `AnimalService` in the logical tree would look like this:
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+         @Inject(AnimalService) animal=>"&#x1F433;">
+  <#VIEW>
+    <app-child>
+      <#VIEW @Provide(AnimalService="&#x1F436;")
+            @Inject(AnimalService=>"&#x1F436;")>
+        <!-- ^^using viewProviders means AnimalService is available in <#VIEW>-->
+        <p>Emoji from AnimalService: {{animal.emoji}} (&#x1F436;)</p>
+
+        <div class="container">
+          <h3>Content projection</h3>
+          <app-inspector @Inject(AnimalService) animal=>"&#x1F433;">
+            <p>Emoji from AnimalService: {{animal.emoji}} (&#x1F433;)</p>
+          </app-inspector>
+        </div>
+
+        <app-inspector>
+          <#VIEW @Inject(AnimalService) animal=>"&#x1F436;">
+            <p>Emoji from AnimalService: {{animal.emoji}} (&#x1F436;)</p>
+          </#VIEW>
+        </app-inspector>
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+The projected content of `<app-inspector>` sees the whale <code>&#x1F433;</code>, not the dog <code>&#x1F436;</code>, because the dog <code>&#x1F436;</code> is inside the `<app-child>` `<#VIEW>`.
+The `<app-inspector>` can only see the dog <code>&#x1F436;</code> if it is also within the `<#VIEW>`.
+
+### Visibility of provided tokens
+
+Visibility decorators influence where the search for the injection token begins and ends in the logic tree.
+To do this, place visibility decorators at the point of injection, that is, the `constructor()`, rather than at a point of declaration.
+
+To alter where the injector starts looking for `FlowerService`, add `@SkipSelf()` to the `<app-child>` `@Inject` declaration where `FlowerService` is injected.
+This declaration is in the `<app-child>` constructor as shown in `child.component.ts`:
+
+<docs-code language="typescript">
+constructor(@SkipSelf() public flower: FlowerService) { }
+</docs-code>
+
+With `@SkipSelf()`, the `<app-child>` injector doesn't look to itself for the `FlowerService`.
+Instead, the injector starts looking for the `FlowerService` at the `ElementInjector` of the `<app-root>`, where it finds nothing.
+Then, it goes back to the `<app-child>` `ModuleInjector` and finds the red hibiscus <code>&#x1F33A;</code> value, which is available because `<app-child>` and `<app-root>` share the same `ModuleInjector`.
+The UI renders the following:
+
+<docs-code hideCopy language="shell">
+
+Emoji from FlowerService: &#x1F33A;
+
+</docs-code>
+
+In a logical tree, this same idea might look like this:
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+        @Inject(FlowerService) flower=>"&#x1F33A;">
+  <#VIEW>
+    <app-child @Provide(FlowerService="&#x1F33B;")>
+      <#VIEW @Inject(FlowerService, SkipSelf)=>"&#x1F33A;">
+        <!-- With SkipSelf, the injector looks to the next injector up the tree (app-root) -->
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+Though `<app-child>` provides the sunflower <code>&#x1F33B;</code>, the application renders the red hibiscus <code>&#x1F33A;</code> because `@SkipSelf()` causes the current injector (`app-child`) to skip itself and look to its parent.
+
+If you now add `@Host()` (in addition to the `@SkipSelf()`), the result will be `null`.
+This is because `@Host()` limits the upper bound of the search to the `app-child` `<#VIEW>`.
+Here's the idea in the logical tree:
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+        @Inject(FlowerService) flower=>"&#x1F33A;">
+  <#VIEW> <!-- end search here with null-->
+    <app-child @Provide(FlowerService="&#x1F33B;")> <!-- start search here -->
+      <#VIEW @Inject(FlowerService, @SkipSelf, @Host, @Optional)=>null>
+      </#VIEW>
+      </app-parent>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+Here, the services and their values are the same, but `@Host()` stops the injector from looking any further than the `<#VIEW>` for `FlowerService`, so it doesn't find it and returns `null`.
+
+### `@SkipSelf()` and `viewProviders`
+
+Remember, `<app-child>` provides the `AnimalService` in the `viewProviders` array with the value of dog <code>&#x1F436;</code>.
+Because the injector has only to look at the `ElementInjector` of the `<app-child>` for the `AnimalService`, it never sees the whale <code>&#x1F433;</code>.
+
+As in the `FlowerService` example, if you add `@SkipSelf()` to the constructor for the `AnimalService`, the injector won't look in the  `ElementInjector` of the current `<app-child>` for the `AnimalService`.
+Instead, the injector will begin at the `<app-root>` `ElementInjector`.
+
+<docs-code language="typescript" highlight="[6]">
+@Component({
+  standalone: true,
+  selector: 'app-child',
+  …
+  viewProviders: [
+    { provide: AnimalService, useValue: { emoji: '&#x1F436;' } },
+  ],
+})
+</docs-code>
+
+The logical tree looks like this with `@SkipSelf()` in `<app-child>`:
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+          @Inject(AnimalService=>"&#x1F433;")>
+  <#VIEW><!-- search begins here -->
+    <app-child>
+      <#VIEW @Provide(AnimalService="&#x1F436;")
+             @Inject(AnimalService, SkipSelf=>"&#x1F433;")>
+        <!--Add @SkipSelf -->
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+With `@SkipSelf()` in the `<app-child>`, the injector begins its search for the `AnimalService` in the `<app-root>` `ElementInjector` and finds whale <code>&#x1F433;</code>.
+
+### `@Host()` and `viewProviders`
+
+If you just use `@Host()` for the injection of `AnimalService`, the result is dog <code>&#x1F436;</code> because the injector finds the `AnimalService` in the `<app-child>` `<#VIEW>` itself.
+The `ChildComponent` configures the `viewProviders` so that the dog emoji is provided as `AnimalService` value.
+You can also see `@Host()` in the constructor:
+
+<docs-code language="typescript" highlight="[[6],[10]]">
+@Component({
+  standalone: true
+  selector: 'app-child',
+  …
+  viewProviders: [
+    { provide: AnimalService, useValue: { emoji: '&#x1F436;' } },
+  ]
+})
+export class ChildComponent {
+  constructor(@Host() public animal: AnimalService) { }
+}
+</docs-code>
+
+`@Host()` causes the injector to look until it encounters the edge of the `<#VIEW>`.
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+          @Inject(AnimalService=>"&#x1F433;")>
+  <#VIEW>
+    <app-child>
+      <#VIEW @Provide(AnimalService="&#x1F436;")
+             @Inject(AnimalService, @Host=>"&#x1F436;")> <!-- @Host stops search here -->
+      </#VIEW>
+    </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+Add a `viewProviders` array with a third animal, hedgehog <code>&#x1F994;</code>, to the `app.component.ts` `@Component()` metadata:
+
+<docs-code language="typescript" highlight="[7]">
+@Component({
+  standalone: true,
+  selector: 'app-root',
+  templateUrl: './app.component.html',
+  styleUrls: [ './app.component.css' ],
+  viewProviders: [
+    { provide: AnimalService, useValue: { emoji: '&#x1F994;' } },
+  ],
+})
+
+</docs-code>
+
+Next, add `@SkipSelf()` along with `@Host()` to the constructor for the `AnimalService` injection in `child.component.ts`.
+Here are `@Host()` and `@SkipSelf()` in the `<app-child>` constructor:
+
+<docs-code language="typescript" highlight="[4]">
+export class ChildComponent {
+
+  constructor(
+    @Host() @SkipSelf() public animal: AnimalService) { }
+}
+
+</docs-code>
+
+<!-- TODO: This requires a rework. It seems not well explained what `viewProviders`/`injectors` is here
+  and how `@Host()` works.
+ -->
+
+When `@Host()` and `@SkipSelf()` were applied to the `FlowerService`, which is in the `providers` array, the result was `null` because `@SkipSelf()` starts its search in the `<app-child>` injector, but `@Host()` stops searching at `<#VIEW>` —where there is no `FlowerService`
+In the logical tree, you can see that the `FlowerService` is visible in `<app-child>`, not its `<#VIEW>`.
+
+However, the `AnimalService`, which is provided in the `AppComponent` `viewProviders` array, is visible.
+
+The logical tree representation shows why this is:
+
+<docs-code language="html">
+
+<app-root @ApplicationConfig
+        @Inject(AnimalService=>"&#x1F433;")>
+  <#VIEW @Provide(AnimalService="&#x1F994;")
+         @Inject(AnimalService, @Optional)=>"&#x1F994;">
+    <!-- ^^@SkipSelf() starts here,  @Host() stops here^^ -->
+    <app-child>
+      <#VIEW @Provide(AnimalService="&#x1F436;")
+             @Inject(AnimalService, @SkipSelf, @Host, @Optional)=>"&#x1F994;">
+               <!-- Add @SkipSelf ^^-->
+      </#VIEW>
+      </app-child>
+  </#VIEW>
+</app-root>
+
+</docs-code>
+
+`@SkipSelf()`, causes the injector to start its search for the `AnimalService` at the `<app-root>`, not the `<app-child>`, where the request originates, and `@Host()` stops the search at the `<app-root>` `<#VIEW>`.
+Since `AnimalService` is provided by way of the `viewProviders` array, the injector finds hedgehog <code>&#x1F994;</code> in the `<#VIEW>`.
+
+## Example: `ElementInjector` use cases
+
+The ability to configure one or more providers at different levels opens up useful possibilities.
+
+### Scenario: service isolation
+
+Architectural reasons may lead you to restrict access to a service to the application domain where it belongs.
+For example, consider we build a `VillainsListComponent` that displays a list of villains.
+It gets those villains from a `VillainsService`.
+
+If you provide `VillainsService` in the root `AppModule`, it will make `VillainsService` visible everywhere in the application.
+If you later modify the `VillainsService`, you could break something in other components that started depending this service by accident.
+
+Instead, you should provide the `VillainsService` in the `providers` metadata of the `VillainsListComponent` like this:
+
+<docs-code header="src/app/villains-list.component.ts (metadata)" language="typescript"
+           highlight="[4]">
+@Component({
+  selector: 'app-villains-list',
+  templateUrl: './villains-list.component.html',
+  providers: [VillainsService]
+})
+export class VillainsListComponent {}
+</docs-code>
+
+By providing `VillainsService` in the `VillainsListComponent` metadata and nowhere else, the service becomes available only in the `VillainsListComponent` and its subcomponent tree.
+
+`VillainService` is a singleton with respect to `VillainsListComponent` because that is where it is declared.
+As long as `VillainsListComponent` does not get destroyed it will be the same instance of `VillainService` but if there are multiple instances of `VillainsListComponent`, then each instance of `VillainsListComponent` will have its own instance of `VillainService`.
+
+### Scenario: multiple edit sessions
+
+Many applications allow users to work on several open tasks at the same time.
+For example, in a tax preparation application, the preparer could be working on several tax returns, switching from one to the other throughout the day.
+
+To demonstrate that scenario, imagine a `HeroListComponent` that displays a list of super heroes.
+
+To open a hero's tax return, the preparer clicks on a hero name, which opens a component for editing that return.
+Each selected hero tax return opens in its own component and multiple returns can be open at the same time.
+
+Each tax return component has the following characteristics:
+
+* Is its own tax return editing session
+* Can change a tax return without affecting a return in another component
+* Has the ability to save the changes to its tax return or cancel them
+
+Suppose that the `HeroTaxReturnComponent` had logic to manage and restore changes.
+That would be a straightforward task for a hero tax return.
+In the real world, with a rich tax return data model, the change management would be tricky.
+You could delegate that management to a helper service, as this example does.
+
+The `HeroTaxReturnService` caches a single `HeroTaxReturn`, tracks changes to that return, and can save or restore it.
+It also delegates to the application-wide singleton `HeroService`, which it gets by injection.
+
+<docs-code header="src/app/hero-tax-return.service.ts" language="typescript">
+import { Injectable } from '@angular/core';
+import { HeroTaxReturn } from './hero';
+import { HeroesService } from './heroes.service';
+
+@Injectable()
+export class HeroTaxReturnService {
+  private currentTaxReturn!: HeroTaxReturn;
+  private originalTaxReturn!: HeroTaxReturn;
+
+  constructor(private heroService: HeroesService) {}
+
+  set taxReturn(htr: HeroTaxReturn) {
+    this.originalTaxReturn = htr;
+    this.currentTaxReturn  = htr.clone();
+  }
+
+  get taxReturn(): HeroTaxReturn {
+    return this.currentTaxReturn;
+  }
+
+  restoreTaxReturn() {
+    this.taxReturn = this.originalTaxReturn;
+  }
+
+  saveTaxReturn() {
+    this.taxReturn = this.currentTaxReturn;
+    this.heroService.saveTaxReturn(this.currentTaxReturn).subscribe();
+  }
+}
+</docs-code>
+
+Here is the `HeroTaxReturnComponent` that makes use of `HeroTaxReturnService`.
+
+<docs-code header="src/app/hero-tax-return.component.ts" language="typescript">
+import { Component, EventEmitter, Input, Output } from '@angular/core';
+import { HeroTaxReturn } from './hero';
+import { HeroTaxReturnService } from './hero-tax-return.service';
+
+@Component({
+  selector: 'app-hero-tax-return',
+  templateUrl: './hero-tax-return.component.html',
+  styleUrls: [ './hero-tax-return.component.css' ],
+  providers: [ HeroTaxReturnService ]
+})
+export class HeroTaxReturnComponent {
+  message = '';
+
+  @Output() close = new EventEmitter<void>();
+
+  get taxReturn(): HeroTaxReturn {
+    return this.heroTaxReturnService.taxReturn;
+  }
+
+  @Input()
+  set taxReturn(htr: HeroTaxReturn) {
+    this.heroTaxReturnService.taxReturn = htr;
+  }
+
+  constructor(private heroTaxReturnService: HeroTaxReturnService) {}
+
+  onCanceled()  {
+    this.flashMessage('Canceled');
+    this.heroTaxReturnService.restoreTaxReturn();
+  }
+
+  onClose() { this.close.emit(); }
+
+  onSaved() {
+    this.flashMessage('Saved');
+    this.heroTaxReturnService.saveTaxReturn();
+  }
+
+  flashMessage(msg: string) {
+    this.message = msg;
+    setTimeout(() => this.message = '', 500);
+  }
+}
+</docs-code>
+
+The _tax-return-to-edit_ arrives by way of the `@Input()` property, which is implemented with getters and setters.
+The setter initializes the component's own instance of the `HeroTaxReturnService` with the incoming return.
+The getter always returns what that service says is the current state of the hero.
+The component also asks the service to save and restore this tax return.
+
+This won't work if the service is an application-wide singleton.
+Every component would share the same service instance, and each component would overwrite the tax return that belonged to another hero.
+
+To prevent this, configure the component-level injector of `HeroTaxReturnComponent` to provide the service, using the `providers` property in the component metadata.
+
+<docs-code header="src/app/hero-tax-return.component.ts (providers)" language="typescript">
+providers: [HeroTaxReturnService]
+</docs-code>
+
+The `HeroTaxReturnComponent` has its own provider of the `HeroTaxReturnService`.
+Recall that every component _instance_ has its own injector.
+Providing the service at the component level ensures that _every_ instance of the component gets a private instance of the service. This makes sure that no tax return gets overwritten.
+
+HELPFUL: The rest of the scenario code relies on other Angular features and techniques that you can learn about elsewhere in the documentation.
+
+### Scenario: specialized providers
+
+Another reason to provide a service again at another level is to substitute a _more specialized_ implementation of that service, deeper in the component tree.
+
+For example, consider a `Car` component that includes tire service information and depends on other services to provide more details about the car.
+
+The root injector, marked as (A), uses _generic_ providers for details about `CarService` and `EngineService`.
+
+1. `Car` component (A).  Component (A) displays tire service data about a car and specifies generic services to provide more information about the car.
+
+2. Child component (B). Component (B) defines its own, _specialized_ providers for `CarService` and `EngineService` that have special capabilities suitable for what's going on in component (B).
+
+3. Child component (C) as a child of Component (B). Component (C) defines its own, even _more specialized_ provider for `CarService`.
+
+```mermaid
+graph TD;
+subgraph COMPONENT_A[Component A]
+subgraph COMPONENT_B[Component B]
+COMPONENT_C[Component C]
+end
+end
+
+style COMPONENT_A fill:#BDD7EE
+style COMPONENT_B fill:#FFE699
+style COMPONENT_C fill:#A9D18E,color:#000
+classDef noShadow filter:none
+class COMPONENT_A,COMPONENT_B,COMPONENT_C noShadow
+```
+
+Behind the scenes, each component sets up its own injector with zero, one, or more providers defined for that component itself.
+
+When you resolve an instance of `Car` at the deepest component (C), its injector produces:
+
+* An instance of `Car` resolved by injector (C)
+* An `Engine` resolved by injector (B)
+* Its `Tires` resolved by the root injector (A).
+
+```mermaid
+graph BT;
+
+subgraph A[" "]
+direction LR
+RootInjector["(A) RootInjector"]
+ServicesA["CarService, EngineService, TiresService"]
+end
+
+subgraph B[" "]
+direction LR
+ParentInjector["(B) ParentInjector"]
+ServicesB["CarService2, EngineService2"]
+end
+
+subgraph C[" "]
+direction LR
+ChildInjector["(C) ChildInjector"]
+ServicesC["CarService3"]
+end
+
+direction LR
+car["(C) Car"]
+engine["(B) Engine"]
+tires["(A) Tires"]
+
+direction BT
+car-->ChildInjector
+ChildInjector-->ParentInjector-->RootInjector
+
+class car,engine,tires,RootInjector,ParentInjector,ChildInjector,ServicesA,ServicesB,ServicesC,A,B,C noShadow
+style car fill:#A9D18E,color:#000
+style ChildInjector fill:#A9D18E,color:#000
+style engine fill:#FFE699,color:#000
+style ParentInjector fill:#FFE699,color:#000
+style tires fill:#BDD7EE,color:#000
+style RootInjector fill:#BDD7EE,color:#000
+```
+
+## More on dependency injection
+
+<docs-pill-row>
+  <docs-pill href="/guide/di/dependency-injection-providers" title="DI Providers"/>
+</docs-pill-row>

From d83d16bf32e88501e1a042e6b3935c208c45cc2b Mon Sep 17 00:00:00 2001
From: Suguru Inatomi <suguru.inatomi@gmail.com>
Date: Sat, 20 Jul 2024 14:16:44 +0900
Subject: [PATCH 2/3] fix: translate hierarchical di guide

---
 .../di/hierarchical-dependency-injection.md   | 668 +++++++++---------
 prh.yml                                       |   5 +-
 2 files changed, 338 insertions(+), 335 deletions(-)

diff --git a/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
index 75465edfb4..f06f3c6700 100644
--- a/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
+++ b/adev-ja/src/content/guide/di/hierarchical-dependency-injection.md
@@ -1,52 +1,52 @@
-# Hierarchical injectors
+## 階層型インジェクター
 
-Injectors in Angular have rules that you can leverage to achieve the desired visibility of injectables in your applications.
-By understanding these rules, you can determine whether to declare a provider at the application level, in a Component, or in a Directive.
+Angularのインジェクターには、注入可能なオブジェクトのアプリケーション内での可視性を思いどおりにするために活用できるルールがあります。
+これらのルールを理解することで、プロバイダーをアプリケーションレベル、コンポーネント内、またはディレクティブ内で宣言する必要があるかどうかを判断できます。
 
-The applications you build with Angular can become quite large, and one way to manage this complexity is to split up the application into a well-defined tree of components.
+Angularで構築するアプリケーションは非常に大きくなる可能性があり、この複雑さを管理する1つの方法は、アプリケーションを明確に定義されたコンポーネントツリーに分割することです。
 
-There can be sections of your page that work in a completely independent way than the rest of the application, with its own local copies of the services and other dependencies that it needs.
-Some of the services that these sections of the application use might be shared with other parts of the application, or with parent components that are further up in the component tree, while other dependencies are meant to be private.
+ページのセクションには、アプリケーションの残りの部分とは完全に独立して動作する部分があり、そのセクションに必要なサービスやその他の依存関係のローカルコピーが持つことができます。
+これらのアプリケーションセクションが使用するサービスの一部は、アプリケーションの他の部分やコンポーネントツリーの上位にある親コンポーネントと共有される場合がありますが、他の依存関係はプライベートであることを目的としています。
 
-With hierarchical dependency injection, you can isolate sections of the application and give them their own private dependencies not shared with the rest of the application, or have parent components share certain dependencies with its child components only but not with the rest of the component tree, and so on. Hierarchical dependency injection enables you to share dependencies between different parts of the application only when and if you need to.
+階層型の依存性の注入を使用すると、アプリケーションのセクションを分離してアプリケーションの残りの部分と共有されていない独自のプライベート依存関係を与えるか、親コンポーネントが特定の依存関係を子コンポーネントのみに共有してコンポーネントツリーの残りの部分には共有しないようにできます。階層型の依存性の注入により、必要な場合にのみ、アプリケーションのさまざまな部分間で依存関係を共有できます。
 
-## Types of injector hierarchies
+## インジェクター階層のタイプ
 
-Angular has two injector hierarchies:
+Angularには、次の2つのインジェクター階層があります。
 
-| Injector hierarchies        | Details |
+| インジェクター階層        | 詳細 |
 |:---                         |:---     |
-| `EnvironmentInjector` hierarchy | Configure an `ElementInjector` in this hierarchy using `@Injectable()` or `providers` array in `ApplicationConfig`. |
-| `ElementInjector` hierarchy | Created implicitly at each DOM element. An `ElementInjector` is empty by default unless you configure it in the `providers` property on `@Directive()` or `@Component()`. |
+| `EnvironmentInjector` 階層 | `@Injectable()` または `ApplicationConfig` の `providers` 配列を使用して、この階層で `ElementInjector` を構成します。 |
+| `ElementInjector` 階層 | 各 DOM 要素で暗黙的に作成されます。 `ElementInjector` は、 `@Directive()` または `@Component()` の `providers` プロパティで構成しない限り、デフォルトでは空です。 |
 
-<docs-callout title="NgModule Based Applications">
-For `NgModule` based applications, you can provide dependencies with the `ModuleInjector` hierarchy using an `@NgModule()` or `@Injectable()` annotation.
+<docs-callout title="NgModule ベースのアプリケーション">
+`NgModule` ベースのアプリケーションの場合、`@NgModule()` または `@Injectable()` アノテーションを使用して、`ModuleInjector` 階層で依存関係を提供できます。
 </docs-callout>
 
 ### `EnvironmentInjector`
 
-The `EnvironmentInjector` can be configured in one of two ways by using:
+`EnvironmentInjector` は、次のいずれかの方法で構成できます。
 
-* The `@Injectable()` `providedIn` property to refer to `root` or `platform`
-* The `ApplicationConfig` `providers` array
+* `@Injectable()` の `providedIn` プロパティを使用して `root` または `platform` を参照する
+* `ApplicationConfig` の `providers` 配列を使用する
 
-<docs-callout title="Tree-shaking and @Injectable()">
+<docs-callout title="ツリーシェイクと @Injectable()">
 
-Using the `@Injectable()` `providedIn` property is preferable to using the `ApplicationConfig` `providers` array. With `@Injectable()` `providedIn`, optimization tools can perform tree-shaking, which removes services that your application isn't using. This results in smaller bundle sizes.
+`@Injectable()` の `providedIn` プロパティを使用することは、 `ApplicationConfig` の `providers` 配列を使用するよりも好ましいです。 `@Injectable()` の `providedIn` を使用すると、最適化ツールはツリーシェイクを実行して、アプリケーションで使用されていないサービスを削除できます。これにより、バンドルサイズが小さくなります。
 
-Tree-shaking is especially useful for a library because the application which uses the library may not have a need to inject it.
+ツリーシェイクは、特にライブラリにとって有用です。なぜなら、ライブラリを使用するアプリケーションは、ライブラリを注入する必要がない場合があるからです。
 
 </docs-callout>
 
-`EnvironmentInjector` is configured by the `ApplicationConfig.providers`.
+`EnvironmentInjector` は、 `ApplicationConfig.providers` によって構成されます。
 
-Provide services using `providedIn` of `@Injectable()` as follows:
+`providedIn` を使用して、次のように `@Injectable()` を使用してサービスを提供します。
 
 <docs-code language="typescript" highlight="[4]">
 import { Injectable } from '@angular/core';
 
 @Injectable({
-  providedIn: 'root'  // <--provides this service in the root EnvironmentInjector
+  providedIn: 'root'  // <--ルート EnvironmentInjector でこのサービスを提供します
 })
 export class ItemService {
   name = 'telephone';
@@ -54,43 +54,43 @@ export class ItemService {
 
 </docs-code>
 
-The `@Injectable()` decorator identifies a service class.
-The `providedIn` property configures a specific `EnvironmentInjector`, here `root`, which makes the service available in the `root` `EnvironmentInjector`.
+`@Injectable()` デコレーターは、サービスクラスを識別します。
+`providedIn` プロパティは、特定の `EnvironmentInjector`（ここでは `root`）を構成します。これにより、サービスは `root` `EnvironmentInjector` で使用可能になります。
 
 ### ModuleInjector
 
-In the case of `NgModule` based applications, the ModuleInjector can be configured in one of two ways by using:
+`NgModule` ベースのアプリケーションの場合、`ModuleInjector` は、次のいずれかの方法で構成できます。
 
-* The `@Injectable()` `providedIn` property to refer to `root` or `platform`
-* The `@NgModule()` `providers` array
+* `@Injectable()` の `providedIn` プロパティを使用して `root` または `platform` を参照する
+* `@NgModule()` の `providers` 配列を使用する
 
-`ModuleInjector` is configured by the `@NgModule.providers` and `NgModule.imports` property. `ModuleInjector` is a flattening of all the providers arrays that can be reached by following the `NgModule.imports` recursively.
+`ModuleInjector` は、 `@NgModule.providers` および `NgModule.imports` プロパティによって構成されます。 `ModuleInjector` は、 `NgModule.imports` を再帰的にたどることによって到達できるすべてのプロバイダー配列をフラット化したものです。
 
-Child `ModuleInjector` hierarchies are created when lazy loading other `@NgModules`.
+子 `ModuleInjector` 階層は、他の `@NgModules` を遅延ロードするときに作成されます。
 
-### Platform injector
+### プラットフォームインジェクター
 
-There are two more injectors above `root`, an additional `EnvironmentInjector` and `NullInjector()`.
+`root` の上にさらに2つのインジェクター、追加の `EnvironmentInjector` と `NullInjector()` があります。
 
-Consider how Angular bootstraps the application with the following in `main.ts`:
+Angularが `main.ts` の次の内容でアプリケーションをブートストラップする方法を検討してください。
 
 <docs-code language="javascript">
 bootstrapApplication(AppComponent, appConfig);
 </docs-code>
 
-The `bootstrapApplication()` method creates a child injector of the platform injector which is configured by the `ApplicationConfig` instance.
-This is the `root` `EnvironmentInjector`.
+`bootstrapApplication()` メソッドは、 `ApplicationConfig` インスタンスによって構成されたプラットフォームインジェクターの子インジェクターを作成します。
+これが `root` `EnvironmentInjector` です。
 
-The `platformBrowserDynamic()` method creates an injector configured by a `PlatformModule`, which contains platform-specific dependencies.
-This allows multiple applications to share a platform configuration.
-For example, a browser has only one URL bar, no matter how many applications you have running.
-You can configure additional platform-specific providers at the platform level by supplying `extraProviders` using the `platformBrowser()` function.
+`platformBrowserDynamic()` メソッドは、プラットフォーム固有の依存関係を含む `PlatformModule` によって構成されたインジェクターを作成します。
+これにより、複数のアプリケーションがプラットフォーム構成を共有できます。
+たとえば、ブラウザには、実行中のアプリケーションの数にかかわらず、URLバーは1つだけです。
+`platformBrowser()` 関数を使用して `extraProviders` を提供することにより、プラットフォームレベルで追加のプラットフォーム固有のプロバイダーを構成できます。
 
-The next parent injector in the hierarchy is the `NullInjector()`, which is the top of the tree.
-If you've gone so far up the tree that you are looking for a service in the `NullInjector()`, you'll get an error unless you've used `@Optional()` because ultimately, everything ends at the `NullInjector()` and it returns an error or, in the case of `@Optional()`, `null`.
-For more information on `@Optional()`, see the [`@Optional()` section](#optional) of this guide.
+階層の次の親インジェクターは `NullInjector()` で、ツリーのトップです。
+ツリーをそこまで上に移動して `NullInjector()` 内でサービスを検索した場合、 `@Optional()` を使用していない限り、エラーが発生します。最終的にはすべて `NullInjector()` で終了し、エラーを返すか、 `@Optional()` の場合、 `null` を返します。
+`@Optional()` の詳細については、このガイドの [`@Optional()` セクション](#optional) を参照してください。
 
-The following diagram represents the relationship between the `root` `ModuleInjector` and its parent injectors as the previous paragraphs describe.
+次の図は、前の段落で説明したように、 `root` `ModuleInjector` とその親インジェクターの関係を表しています。
 
 ```mermaid
 stateDiagram-v2
@@ -103,17 +103,17 @@ stateDiagram-v2
     elementInjector --> nullInjector
 ```
 
-While the name `root` is a special alias, other `EnvironmentInjector` hierarchies don't have aliases.
-You have the option to create `EnvironmentInjector` hierarchies whenever a dynamically loaded component is created, such as with the Router, which will create child `EnvironmentInjector` hierarchies.
+`root` という名前は特別なエイリアスですが、他の `EnvironmentInjector` 階層にはエイリアスがありません。
+動的にロードされたコンポーネントが作成されるたびに `EnvironmentInjector` 階層を作成するオプションがあります。たとえば、ルーターを使用すると、子 `EnvironmentInjector` 階層が作成されます。
 
-All requests forward up to the root injector, whether you configured it with the `ApplicationConfig` instance passed to the `bootstrapApplication()` method, or registered all providers with `root` in their own services.
+`ApplicationConfig` インスタンスを `bootstrapApplication()` メソッドに渡して構成するか、 `root` で独自のサービスにすべてのプロバイダーを登録したかにかかわらず、すべての要求はルートインジェクターに転送されます。
 
 <docs-callout title="@Injectable() vs. ApplicationConfig">
 
-If you configure an app-wide provider in the `ApplicationConfig` of `bootstrapApplication`, it overrides one configured for `root` in the `@Injectable()` metadata.
-You can do this to configure a non-default provider of a service that is shared with multiple applications.
+`bootstrapApplication()` の `ApplicationConfig` でアプリケーション全体のプロバイダーを構成すると、 `@Injectable()` メタデータの `root` で構成されたプロバイダーがオーバーライドされます。
+これは、複数のアプリケーションで共有されるサービスのデフォルト以外を構成する場合に行うことができます。
 
-Here is an example of the case where the component router configuration includes a non-default [location strategy](guide/routing#location-strategy) by listing its provider in the `providers` list of the `ApplicationConfig`.
+コンポーネントルーターの構成にデフォルト以外の [ロケーション戦略](guide/routing#location-strategy) が含まれている場合、 `ApplicationConfig` の `providers` リストにそのプロバイダーをリストすることによって、その例を示します。
 
 ```ts
 providers: [
@@ -121,16 +121,16 @@ providers: [
 ]
 ```
 
-For `NgModule` based applications, configure app-wide providers in the `AppModule` `providers`.
+`NgModule` ベースのアプリケーションの場合、アプリケーション全体のプロバイダーを `AppModule` の `providers` で構成します。
 
 </docs-callout>
 
 ### `ElementInjector`
 
-Angular creates `ElementInjector` hierarchies implicitly for each DOM element.
+Angularは、各DOM要素に対して `ElementInjector` 階層を暗黙的に作成します。
 
-Providing a service in the `@Component()` decorator using its `providers` or `viewProviders` property configures an `ElementInjector`.
-For example, the following `TestComponent` configures the `ElementInjector` by providing the service as follows:
+`@Component()` デコレーターの `providers` または `viewProviders` プロパティを使用してサービスを提供すると、 `ElementInjector` が構成されます。
+たとえば、次の `TestComponent` は、次のようにサービスを提供することで `ElementInjector` を構成します。
 
 <docs-code language="typescript" highlight="[3]">
 @Component({
@@ -140,67 +140,67 @@ For example, the following `TestComponent` configures the `ElementInjector` by p
 export class TestComponent
 </docs-code>
 
-HELPFUL: See the [resolution rules](#resolution-rules) section to understand the relationship between the `EnvironmentInjector` tree, the `ModuleInjector` and the `ElementInjector` tree.
+HELPFUL: [解決ルール](#resolution-rules) セクションを参照して、 `EnvironmentInjector` ツリー、 `ModuleInjector`、および `ElementInjector` ツリーの関係を理解してください。
 
-When you provide services in a component, that service is available by way of the `ElementInjector` at that component instance.
-It may also be visible at child component/directives based on visibility rules described in the [resolution rules](#resolution-rules) section.
+コンポーネントでサービスを提供すると、そのサービスは、そのコンポーネントインスタンスの `ElementInjector` を介して使用可能になります。
+[解決ルール](#resolution-rules) セクションで説明されている可視性ルールに基づいて、子コンポーネント/ディレクティブでも可視化される可能性があります。
 
-When the component instance is destroyed, so is that service instance.
+コンポーネントインスタンスが破棄されると、そのサービスインスタンスも破棄されます。
 
-#### `@Directive()` and `@Component()`
+#### `@Directive()` と `@Component()`
 
-A component is a special type of directive, which means that just as `@Directive()` has a `providers` property, `@Component()` does too.
-This means that directives as well as components can configure providers, using the `providers` property.
-When you configure a provider for a component or directive using the `providers` property, that provider belongs to the `ElementInjector` of that component or directive.
-Components and directives on the same element share an injector.
+コンポーネントは特殊なタイプのディレクティブであるため、 `@Directive()` に `providers` プロパティがあるように、 `@Component()` にも `providers` プロパティがあります。
+つまり、ディレクティブとコンポーネントは、 `providers` プロパティを使用してプロバイダーを構成できます。
+`providers` プロパティを使用してコンポーネントまたはディレクティブのプロバイダーを構成すると、そのプロバイダーはそのコンポーネントまたはディレクティブの `ElementInjector` に属します。
+同じ要素上のコンポーネントとディレクティブは、インジェクターを共有します。
 
-## Resolution rules
+## 解決ルール
 
-When resolving a token for a component/directive, Angular resolves it in two phases:
+コンポーネント/ディレクティブのトークンを解決する場合、Angularは次の2つのフェーズで解決します。
 
-1. Against its parents in the `ElementInjector` hierarchy.
-2. Against its parents in the `EnvironmentInjector` hierarchy.
+1. `ElementInjector` 階層の親に対して。
+2. `EnvironmentInjector` 階層の親に対して。
 
-When a component declares a dependency, Angular tries to satisfy that dependency with its own `ElementInjector`.
-If the component's injector lacks the provider, it passes the request up to its parent component's `ElementInjector`.
+コンポーネントが依存関係を宣言すると、Angularはその依存関係を自身の `ElementInjector` で満たそうとします。
+コンポーネントのインジェクターにプロバイダーがない場合、そのリクエストを親コンポーネントの `ElementInjector` に渡します。
 
-The requests keep forwarding up until Angular finds an injector that can handle the request or runs out of ancestor `ElementInjector` hierarchies.
+リクエストは、Angularがリクエストを処理できるインジェクターを見つけるか、祖先 `ElementInjector` 階層を使い果たすまで、転送され続けます。
 
-If Angular doesn't find the provider in any `ElementInjector` hierarchies, it goes back to the element where the request originated and looks in the `EnvironmentInjector` hierarchy.
-If Angular still doesn't find the provider, it throws an error.
+Angularがいずれの `ElementInjector` 階層でもプロバイダーを見つけられない場合、リクエストが発生した要素に戻り、 `EnvironmentInjector` 階層を調べます。
+それでもAngularがプロバイダーを見つけられない場合、エラーをスローします。
 
-If you have registered a provider for the same DI token at different levels, the first one Angular encounters is the one it uses to resolve the dependency.
-If, for example, a provider is registered locally in the component that needs a service,
-Angular doesn't look for another provider of the same service.
+同じDIトークンのプロバイダーを異なるレベルで登録した場合、Angularが最初に遭遇するプロバイダーが、依存関係を解決するために使用するプロバイダーです。
+たとえば、サービスを必要とするコンポーネントにプロバイダーがローカルに登録されている場合、
+Angularは同じサービスの別のプロバイダーを探しません。
 
-HELPFUL: For `NgModule` based applications, Angular will search the `ModuleInjector` hierarchy if it cannot find a provider in the `ElementInjector` hierarchies.
+HELPFUL: `NgModule` ベースのアプリケーションの場合、Angularは `ElementInjector` 階層でプロバイダーが見つからない場合、 `ModuleInjector` 階層を検索します。
 
-## Resolution modifiers
+## 解決修飾子
 
-Angular's resolution behavior can be modified with `@Optional()`, `@Self()`, `@SkipSelf()` and `@Host()`.
-Import each of them from `@angular/core` and use each in the component class constructor or in the `inject` configuration when you inject your service.
+Angularの解決動作は、 `@Optional()`と`@Self()`、`@SkipSelf()`および`@Host()`で変更できます。
+これらのそれぞれを `@angular/core` からインポートし、コンポーネントクラスコンストラクターまたはサービスを注入するときの `inject` 構成でそれぞれを使用します。
 
-### Types of modifiers
+### 修飾子の種類
 
-Resolution modifiers fall into three categories:
+解決修飾子は、次の3つのカテゴリーに分類されます。
 
-* What to do if Angular doesn't find what you're looking for, that is `@Optional()`
-* Where to start looking, that is `@SkipSelf()`
-* Where to stop looking, `@Host()` and `@Self()`
+* Angularが探しているものが見つからない場合の処理、つまり `@Optional()`
+* 検索を開始する場所、つまり `@SkipSelf()`
+* 検索を停止する場所、 `@Host()` と `@Self()`
 
-By default, Angular always starts at the current `Injector` and keeps searching all the way up.
-Modifiers allow you to change the starting, or _self_, location and the ending location.
+デフォルトでは、Angularは常に現在の `Injector` から始めて、すべてを上に検索し続けます。
+修飾子を使用すると、開始位置（または _self_ 位置）と終了位置を変更できます。
 
-Additionally, you can combine all of the modifiers except:
+さらに、次の修飾子をすべて組み合わせることができます。
 
-* `@Host()` and `@Self()`
-* `@SkipSelf()` and `@Self()`.
+* `@Host()` と `@Self()`
+* `@SkipSelf()` と `@Self()`
 
 ### `@Optional()`
 
-`@Optional()` allows Angular to consider a service you inject to be optional.
-This way, if it can't be resolved at runtime, Angular resolves the service as `null`, rather than throwing an error.
-In the following example, the service, `OptionalService`, isn't provided in the service, `ApplicationConfig`, `@NgModule()`, or component class, so it isn't available anywhere in the app.
+`@Optional()` を使用すると、注入するサービスをオプションとして扱うことができます。
+そのため、実行時に解決できない場合、Angularはサービスをエラーをスローするのではなく、 `null` として解決します。
+次の例では、サービス `OptionalService` はサービス `ApplicationConfig`や`@NgModule()`、コンポーネントクラスで提供されていないため、アプリケーションのどこにも使用できません。
 
 <docs-code header="src/app/optional/optional.component.ts" language="typescript">
 export class OptionalComponent {
@@ -210,12 +210,12 @@ export class OptionalComponent {
 
 ### `@Self()`
 
-Use `@Self()` so that Angular will only look at the `ElementInjector` for the current component or directive.
+`@Self()` を使用すると、Angularは現在のコンポーネントまたはディレクティブの `ElementInjector` のみを調べます。
 
-A good use case for `@Self()` is to inject a service but only if it is available on the current host element.
-To avoid errors in this situation, combine `@Self()` with `@Optional()`.
+`@Self()` の良いユースケースは、サービスを注入することですが、現在のホスト要素で使用可能な場合のみです。
+この状況でエラーを回避するには、 `@Self()` と `@Optional()` を組み合わせます。
 
-For example, in the following `SelfComponent`, notice the injected `LeafService` in the constructor.
+たとえば、次の `SelfComponent` では、コンストラクターで注入された `LeafService` に注目してください。
 
 <docs-code header="src/app/self-no-data/self-no-data.component.ts" language="typescript"
            highlight="[7]">
@@ -229,20 +229,20 @@ export class SelfNoDataComponent {
 }
 </docs-code>
 
-In this example, there is a parent provider and injecting the service will return the value, however, injecting the service with `@Self()` and `@Optional()` will return `null` because `@Self()` tells the injector to stop searching in the current host element.
+この例では親プロバイダーがあり、サービスを注入すると値が返されます。しかし `@Self()` と `@Optional()` を使用してサービスを注入すると、 `null` が返されます。これは、 `@Self()` がインジェクターに現在のホスト要素の検索を停止するように指示するためです。
 
-Another example shows the component class with a provider for `FlowerService`.
-In this case, the injector looks no further than the current `ElementInjector` because it finds the `FlowerService` and returns the tulip <code>&#x1F337;</code>.
+別の例では、 `FlowerService` のプロバイダーを備えたコンポーネントクラスを示しています。
+この場合、インジェクターは現在の `ElementInjector` より先を見ずに、 `FlowerService` を見つけて、チューリップ <code>&#x1F337;</code> を返します。
 
 <docs-code header="src/app/self/self.component.ts" path="adev/src/content/examples/resolution-modifiers/src/app/self/self.component.ts" visibleRegion="self-component"/>
 
 ### `@SkipSelf()`
 
-`@SkipSelf()` is the opposite of `@Self()`.
-With `@SkipSelf()`, Angular starts its search for a service in the parent `ElementInjector`, rather than in the current one.
-So if the parent `ElementInjector` were using the fern <code>&#x1F33F;</code> value for `emoji`, but you had maple leaf <code>&#x1F341;</code> in the component's `providers` array, Angular would ignore maple leaf <code>&#x1F341;</code> and use fern <code>&#x1F33F;</code>.
+`@SkipSelf()` は `@Self()` の逆です。
+`@SkipSelf()` を使用すると、Angular は現在のインジェクターではなく、親 `ElementInjector` でサービスの検索を開始します。
+そのため、親 `ElementInjector` が `emoji` にシダ <code>&#x1F33F;</code> 値を使用していたが、コンポーネントの `providers` 配列にカエデの葉 <code>&#x1F341;</code> が含まれている場合、Angular はカエデの葉 <code>&#x1F341;</code> を無視して、シダ <code>&#x1F33F;</code> を使用します。
 
-To see this in code, assume that the following value for `emoji` is what the parent component were using, as in this service:
+これをコードで確認するために、親コンポーネントが使用する `emoji` の次の値を想定します。これは、このサービスと同じです。
 
 <docs-code header="src/app/leaf.service.ts" language="typescript">
 export class LeafService {
@@ -250,8 +250,8 @@ export class LeafService {
 }
 </docs-code>
 
-Imagine that in the child component, you had a different value, maple leaf <code>&#x1F341;</code> but you wanted to use the parent's value instead.
-This is when you'd use `@SkipSelf()`:
+子コンポーネントに、異なる値、カエデの葉 <code>&#x1F341;</code> が含まれていると想像してください。ただし、親の値を使用したいとします。
+これが、 `@SkipSelf()` を使用するタイミングです。
 
 <docs-code header="src/app/skipself/skipself.component.ts" language="typescript"
            highlight="[[6],[10]]">
@@ -259,23 +259,23 @@ This is when you'd use `@SkipSelf()`:
   selector: 'app-skipself',
   templateUrl: './skipself.component.html',
   styleUrls: ['./skipself.component.css'],
-  // Angular would ignore this LeafService instance
+  // Angular はこの LeafService インスタンスを無視します
   providers: [{ provide: LeafService, useValue: { emoji: '🍁' } }]
 })
 export class SkipselfComponent {
-  // Use @SkipSelf() in the constructor
+  // コンストラクターで @SkipSelf() を使用します
   constructor(@SkipSelf() public leaf: LeafService) { }
 }
 </docs-code>
 
-In this case, the value you'd get for `emoji` would be fern <code>&#x1F33F;</code>, not maple leaf <code>&#x1F341;</code>.
+この場合、 `emoji` に対して取得する値は、カエデの葉 <code>&#x1F341;</code> ではなく、シダ <code>&#x1F33F;</code> になります。
 
-#### `@SkipSelf()` with `@Optional()`
+#### `@SkipSelf()` と `@Optional()`
 
-Use `@SkipSelf()` with `@Optional()` to prevent an error if the value is `null`.
+`@SkipSelf()` と `@Optional()` を使用すると、値が `null` の場合にエラーを防ぐことができます。
 
-In the following example, the `Person` service is injected in the constructor.
-`@SkipSelf()` tells Angular to skip the current injector and `@Optional()` will prevent an error should the `Person` service be `null`.
+次の例では、 `Person` サービスがコンストラクターで注入されています。
+`@SkipSelf()` は、Angularに現在のインジェクターをスキップするように指示し、 `@Optional()` は `Person` サービスが `null` の場合にエラーを防ぎます。
 
 <docs-code language="typescript">
 class Person {
@@ -285,12 +285,12 @@ class Person {
 
 ### `@Host()`
 
-<!-- TODO: Remove ambiguity between @Host and @Self. -->
+<!-- TODO: @Host と @Self のあいまいさを解消する。 -->
 
-`@Host()` lets you designate a component as the last stop in the injector tree when searching for providers.
+`@Host()` を使用すると、インジェクターツリーでプロバイダーを検索する際の終点としてコンポーネントを指定できます。
 
-Even if there is a service instance further up the tree, Angular won't continue looking.
-Use `@Host()` as follows:
+ツリーの上位にサービスインスタンスがある場合でも、Angularは検索を続行しません。
+`@Host()` は次のように使用します。
 
 <docs-code header="src/app/host/host.component.ts" language="typescript"
            highlight="[[6],[10]]">
@@ -298,24 +298,24 @@ Use `@Host()` as follows:
   selector: 'app-host',
   templateUrl: './host.component.html',
   styleUrls: ['./host.component.css'],
-  //  provide the service
+  // サービスを提供します
   providers: [{ provide: FlowerService, useValue: { emoji: '🌷' } }]
 })
 export class HostComponent {
-  // use @Host() in the constructor when injecting the service
+  // サービスを注入するときにコンストラクターで @Host() を使用します
   constructor(@Host() @Optional() public flower?: FlowerService) { }
 }
 </docs-code>
 
-Since `HostComponent` has `@Host()` in its constructor, no matter what the parent of `HostComponent` might have as a `flower.emoji` value, the `HostComponent` will use tulip <code>&#x1F337;</code>.
+`HostComponent` に `@Host()` があるため、 `HostComponent` の親が `flower.emoji` 値として何を使用しているかに関係なく、 `HostComponent` はチューリップ <code>&#x1F337;</code> を使用します。
 
-## Logical structure of the template
+## テンプレートの論理構造
 
-When you provide services in the component class, services are visible within the `ElementInjector` tree relative to where and how you provide those services.
+コンポーネントクラスでサービスを提供する場合、サービスは、サービスの提供場所と方法に応じて、 `ElementInjector` ツリー内で可視になります。
 
-Understanding the underlying logical structure of the Angular template will give you a foundation for configuring services and in turn control their visibility.
+Angularテンプレートの基になる論理構造を理解すると、サービスの構成と、その可視性の制御のための基礎が得られます。
 
-Components are used in your templates, as in the following example:
+コンポーネントは、次の例のようにテンプレートで使用されます。
 
 <docs-code language="html">
 <app-root>
@@ -323,55 +323,55 @@ Components are used in your templates, as in the following example:
 </app-root>
 </docs-code>
 
-HELPFUL: Usually, you declare the components and their templates in separate files.
-For the purposes of understanding how the injection system works, it is useful to look at them from the point of view of a combined logical tree.
-The term _logical_ distinguishes it from the render tree, which is your application's DOM tree.
-To mark the locations of where the component templates are located, this guide uses the `<#VIEW>` pseudo-element, which doesn't actually exist in the render tree and is present for mental model purposes only.
+HELPFUL: 通常、コンポーネントとそのテンプレートは別々のファイルに宣言します。
+注入システムの動作を理解するために、それらを組み合わせた論理ツリーの視点から見ると便利です。
+用語 _論理_ は、アプリケーションのDOMツリーであるレンダリングツリーと区別しています。
+コンポーネントテンプレートの場所を示すために、このガイドでは `<#VIEW>` 疑似要素を使用します。この疑似要素は、レンダリングツリーには実際に存在せず、メンタルモデルの目的でのみ存在します。
 
-The following is an example of how the `<app-root>` and `<app-child>` view trees are combined into a single logical tree:
+以下は、 `<app-root>` と `<app-child>` のビューツリーを1つの論理ツリーに結合した例です。
 
 <docs-code language="html">
 <app-root>
   <#VIEW>
     <app-child>
      <#VIEW>
-       …content goes here…
+       …ここにコンテンツが挿入されます…
      </#VIEW>
     </app-child>
   </#VIEW>
 </app-root>
 </docs-code>
 
-Understanding the idea of the `<#VIEW>` demarcation is especially significant when you configure services in the component class.
+`<#VIEW>` の区切りの考え方を理解することは、特にコンポーネントクラスでサービスを構成する場合に重要です。
 
-## Example: Providing services in `@Component()`
+## 例： `@Component()` でサービスを提供する
 
-How you provide services using a `@Component()` (or `@Directive()`) decorator determines their visibility.
-The following sections demonstrate `providers` and `viewProviders` along with ways to modify service visibility with `@SkipSelf()` and `@Host()`.
+`@Component()`（または `@Directive()`）デコレーターを使用してサービスを提供する方法は、サービスの可視性を決めます。
+次のセクションでは`providers`と`viewProviders`、`@SkipSelf()`および`@Host()`を使用してサービスの可視性を変更する方法について説明します。
 
-A component class can provide services in two ways:
+コンポーネントクラスでは、次の2つの方法でサービスを提供できます。
 
-| Arrays                       | Details |
+| 配列                       | 詳細 |
 |:---                          |:---     |
-| With a `providers` array     | `@Component({ providers: [SomeService] })`     |
-| With a `viewProviders` array | `@Component({ viewProviders: [SomeService] })` |
+| `providers` 配列を使用する     | `@Component({ providers: [SomeService] })`     |
+| `viewProviders` 配列を使用する | `@Component({ viewProviders: [SomeService] })` |
 
-In the examples below, you will see the logical tree of an Angular application.
-To illustrate how the injector works in the context of templates, the logical tree will represent the HTML structure of the application.
-For example, the logical tree will show that `<child-component>` is a direct children of `<parent-component>`.
+次の例では、Angularアプリケーションの論理ツリーが表示されます。
+テンプレートのコンテキストでインジェクターがどのように動作するかを示すために、論理ツリーはアプリケーションのHTML構造を表します。
+たとえば、論理ツリーは、 `<child-component>` が `<parent-component>` の直接の子であることを示します。
 
-In the logical tree, you will see special attributes: `@Provide`, `@Inject`, and `@ApplicationConfig`.
-These aren't real attributes but are here to demonstrate what is going on under the hood.
+論理ツリーでは、 `@Provide` 、 `@Inject` 、および `@ApplicationConfig` という特殊な属性が表示されます。
+これらは実際の属性ではなく、内部で何が起こっているかを説明するためにここにあります。
 
-| Angular service attribute                                                                                          | Details |
+| Angular サービス属性                                                                                          | 詳細 |
 |:---                                                                                                                |:---     |
-| `@Inject(Token)=>Value`     | If `Token` is injected at this location in the logical tree, its value would be `Value`.     |
-| `@Provide(Token=Value)`     | Indicates that `Token` is provided with `Value` at this location in the logical tree.        |
-| `@ApplicationConfig` | Demonstrates that a fallback `EnvironmentInjector` should be used at this location.          |
+| `@Inject(Token)=>Value`     | 論理ツリーのこの場所に `Token` が注入されている場合、その値は `Value` になります。     |
+| `@Provide(Token=Value)`     | 論理ツリーのこの場所に `Token` が `Value` で提供されていることを示します。        |
+| `@ApplicationConfig` | この場所でフォールバック `EnvironmentInjector` を使用する必要があることを示します。          |
 
-### Example app structure
+### アプリケーション構造の例
 
-The example application has a `FlowerService` provided in `root` with an `emoji` value of red hibiscus <code>&#x1F33A;</code>.
+この例では、 `emoji` の値が赤いハイビスカス <code>&#x1F33A;</code> である、 `root` に提供される `FlowerService` があります。
 
 <docs-code header="src/app/flower.service.ts" language="typescript">
 @Injectable({
@@ -382,24 +382,24 @@ export class FlowerService {
 }
 </docs-code>
 
-Consider an application with only an `AppComponent` and a `ChildComponent`.
-The most basic rendered view would look like nested HTML elements such as the following:
+`AppComponent` と `ChildComponent` のみが含まれるアプリケーションを検討してください。
+最も基本的なレンダリングされたビューは、次のようなネストされたHTML要素のように見えます。
 
 <docs-code language="html">
 
-<app-root> <!-- AppComponent selector -->
-  <app-child> <!-- ChildComponent selector -->
+<app-root> <!-- AppComponent セレクター -->
+  <app-child> <!-- ChildComponent セレクター -->
   </app-child>
 </app-root>
 
 </docs-code>
 
-However, behind the scenes, Angular uses a logical view representation as follows when resolving injection requests:
+ただし、裏側では、Angularはインジェクションリクエストを解決するときに、次のような論理ビュー表現を使用します。
 
 <docs-code language="html">
-<app-root> <!-- AppComponent selector -->
+<app-root> <!-- AppComponent セレクター -->
   <#VIEW>
-    <app-child> <!-- ChildComponent selector -->
+    <app-child> <!-- ChildComponent セレクター -->
       <#VIEW>
       </#VIEW>
     </app-child>
@@ -407,12 +407,12 @@ However, behind the scenes, Angular uses a logical view representation as follow
 </app-root>
 </docs-code>
 
-The `<#VIEW>` here represents an instance of a template.
-Notice that each component has its own `<#VIEW>`.
+ここでの `<#VIEW>` は、テンプレートのインスタンスを表しています。
+各コンポーネントには、独自の `<#VIEW>` があることに注意してください。
 
-Knowledge of this structure can inform how you provide and inject your services, and give you complete control of service visibility.
+この構造を理解することで、サービスの提供方法と注入方法を把握し、サービスの可視性を完全に制御できます。
 
-Now, consider that `<app-root>` injects the `FlowerService`:
+次に、 `<app-root>` が `FlowerService` を注入しているとします。
 
 <docs-code header="src/app/app.component.ts" language="typescript">
 export class AppComponent  {
@@ -420,19 +420,19 @@ export class AppComponent  {
 }
 </docs-code>
 
-Add a binding to the `<app-root>` template to visualize the result:
+結果を視覚化するために、 `<app-root>` テンプレートにバインディングを追加します。
 
 <docs-code header="src/app/app.component.html" language="html">
 <p>Emoji from FlowerService: {{flower.emoji}}</p>
 </docs-code>
 
-The output in the view would be:
+ビューに出力されるのは次のとおりです。
 
 <docs-code language="shell">
 Emoji from FlowerService: &#x1F33A;
 </docs-code>
 
-In the logical tree, this would be represented as follows:
+論理ツリーでは、これは次のように表されます。
 
 <docs-code language="html" highlight="[[1],[2],[4]]">
 <app-root @ApplicationConfig
@@ -448,29 +448,29 @@ In the logical tree, this would be represented as follows:
 
 </docs-code>
 
-When `<app-root>` requests the `FlowerService`, it is the injector's job to resolve the `FlowerService` token.
-The resolution of the token happens in two phases:
+`<app-root>` が `FlowerService` を要求すると、インジェクターは `FlowerService` トークンを解決します。
+トークンの解決は次の2つのフェーズで行われます。
 
-1. The injector determines the starting location in the logical tree and an ending location of the search.
-    The injector begins with the starting location and looks for the token at each view level in the logical tree.
-    If the token is found it is returned.
+1. インジェクターは、論理ツリー内の開始位置と検索の終了位置を決定します。
+    インジェクターは開始位置から始めて、論理ツリーの各ビューレベルでトークンを検索します。
+    トークンが見つかると、そのトークンが返されます。
 
-1. If the token is not found, the injector looks for the closest parent `EnvironmentInjector` to delegate the request to.
+1. トークンが見つからない場合、インジェクターはリクエストを委任する最も近い親 `EnvironmentInjector` を検索します。
 
-In the example case, the constraints are:
+この例の場合、制約は次のとおりです。
 
-1. Start with `<#VIEW>` belonging to `<app-root>` and end with `<app-root>`.
+1. `<app-root>` に属する `<#VIEW>` から始めて、 `<app-root>` で終了します。
 
-    * Normally the starting point for search is at the point of injection.
-        However, in this case `<app-root>` is a component. `@Component`s are special in that they also include their own `viewProviders`, which is why the search starts at `<#VIEW>` belonging to `<app-root>`.
-        This would not be the case for a directive matched at the same location.
-    * The ending location happens to be the same as the component itself, because it is the topmost component in this application.
+    * 通常、検索の開始点は注入ポイントです。
+        ただし、この場合、 `<app-root>` はコンポーネントです。 `@Component` は特殊で、独自の `viewProviders` も含まれています。そのため、検索は `<app-root>` に属する `<#VIEW>` から開始されます。
+        これは、同じ場所に一致するディレクティブでは発生しません。
+    * 終了位置は、コンポーネント自体と同じになります。なぜなら、これはこのアプリケーションの最上位コンポーネントだからです。
 
-1. The `ElementInjector` provided by the `ApplicationConfig` acts as the fallback injector when the injection token can't be found in the `ElementInjector` hierarchies.
+1. `ApplicationConfig` によって提供される `ElementInjector` は、インジェクショントークンが `ElementInjector` 階層で見つからない場合のフォールバックインジェクターとして機能します。
 
-### Using the `providers` array
+### `providers` 配列を使用する
 
-Now, in the `ChildComponent` class, add a provider for `FlowerService` to demonstrate more complex resolution rules in the upcoming sections:
+次に、 `ChildComponent` クラスで、今後のセクションでより複雑な解決ルールを説明するために、 `FlowerService` のプロバイダーを追加します。
 
 <docs-code header="src/app/child.component.ts" language="typescript"
            highlight="[[5,6],[10]]">
@@ -478,32 +478,32 @@ Now, in the `ChildComponent` class, add a provider for `FlowerService` to demons
   selector: 'app-child',
   templateUrl: './child.component.html',
   styleUrls: ['./child.component.css'],
-  // use the providers array to provide a service
+  // プロバイダー配列を使用してサービスを提供します
   providers: [{ provide: FlowerService, useValue: { emoji: '🌻' } }]
 })
 export class ChildComponent {
-  // inject the service
+  // サービスを注入します
   constructor( public flower: FlowerService) { }
 }
 </docs-code>
 
-Now that the `FlowerService` is provided in the `@Component()` decorator, when the `<app-child>` requests the service, the injector has only to look as far as the `ElementInjector` in the `<app-child>`.
-It won't have to continue the search any further through the injector tree.
+`FlowerService` が `@Component()` デコレーターで提供されるようになったため、 `<app-child>` がサービスを要求すると、インジェクターは `<app-child>` の `ElementInjector` ほど遠くまでしか見なくてもよくなります。
+インジェクターは、インジェクターツリーをさらに検索する必要はありません。
 
-The next step is to add a binding to the `ChildComponent` template.
+次のステップは、 `ChildComponent` テンプレートにバインディングを追加することです。
 
 <docs-code header="src/app/child.component.html" language="html">
 <p>Emoji from FlowerService: {{flower.emoji}}</p>
 </docs-code>
 
-To render the new values, add `<app-child>` to the bottom of the `AppComponent` template so the view also displays the sunflower:
+新しい値をレンダリングするために、ビューにひまわりも表示されるように、 `AppComponent` テンプレートの下部に `<app-child>` を追加します。
 
 <docs-code language="shell">
 Child Component
 Emoji from FlowerService: &#x1F33B;
 </docs-code>
 
-In the logical tree, this is represented as follows:
+論理ツリーでは、これは次のように表されます。
 
 <docs-code language="html">
 
@@ -512,8 +512,8 @@ In the logical tree, this is represented as follows:
   <#VIEW>
     <p>Emoji from FlowerService: {{flower.emoji}} (&#x1F33A;)</p>
     <app-child @Provide(FlowerService="&#x1F33B;")
-               @Inject(FlowerService)=>"&#x1F33B;"> <!-- search ends here -->
-      <#VIEW> <!-- search starts here -->
+               @Inject(FlowerService)=>"&#x1F33B;"> <!-- 検索はここで終了します -->
+      <#VIEW> <!-- 検索はここで開始します -->
         <h2>Child Component</h2>
         <p>Emoji from FlowerService: {{flower.emoji}} (&#x1F33B;)</p>
       </#VIEW>
@@ -523,23 +523,23 @@ In the logical tree, this is represented as follows:
 
 </docs-code>
 
-When `<app-child>` requests the `FlowerService`, the injector begins its search at the `<#VIEW>` belonging to `<app-child>` \(`<#VIEW>` is included because it is injected from `@Component()`\) and ends with `<app-child>`.
-In this case, the `FlowerService` is resolved in the `providers` array with sunflower <code>&#x1F33B;</code> of the `<app-child>`.
-The injector doesn't have to look any further in the injector tree.
-It stops as soon as it finds the `FlowerService` and never sees the red hibiscus <code>&#x1F33A;</code>.
+`<app-child>` が `FlowerService` を要求すると、インジェクターは `<app-child>` に属する `<#VIEW>`（`@Component()` から注入されるため `<#VIEW>` が含まれています）から始めて、 `<app-child>` で終了します。
+この場合、 `FlowerService` は、 `<app-child>` の `providers` 配列で、ひまわり <code>&#x1F33B;</code> を使用して解決されます。
+インジェクターは、インジェクターツリーをさらに検索する必要はありません。
+`FlowerService` を見つけるとすぐに停止し、赤いハイビスカス <code>&#x1F33A;</code> は見えません。
 
-### Using the `viewProviders` array
+### `viewProviders` 配列を使用する
 
-Use the `viewProviders` array as another way to provide services in the `@Component()` decorator.
-Using `viewProviders` makes services visible in the `<#VIEW>`.
+`viewProviders` 配列は、 `@Component()` デコレーターでサービスを提供する別の方法です。
+`viewProviders` を使用すると、サービスは `<#VIEW>` で可視になります。
 
-HELPFUL: The steps are the same as using the `providers` array, with the exception of using the `viewProviders` array instead.
+HELPFUL: ステップは `providers` 配列を使用する場合と同じですが、 `viewProviders` 配列を使用する点が異なります。
 
-For step-by-step instructions, continue with this section.
-If you can set it up on your own, skip ahead to [Modifying service availability](#visibility-of-provided-tokens).
+ステップバイステップの手順については、このセクションを続行してください。
+自分で設定できる場合は、[サービスの可用性を変更する](#visibility-of-provided-tokens) に進んでください。
 
-For demonstration, we are building an `AnimalService` to demonstrate `viewProviders`.
-First, create an `AnimalService` with an `emoji` property of whale <code>&#x1F433;</code>:
+デモのために、 `AnimalService` を作成して、 `viewProviders` を示します。
+最初に、 `emoji` プロパティがクジラ <code>&#x1F433;</code> である `AnimalService` を作成します。
 
 <docs-code header="src/app/animal.service.ts" language="typescript">
 import { Injectable } from '@angular/core';
@@ -552,7 +552,7 @@ export class AnimalService {
 }
 </docs-code>
 
-Following the same pattern as with the `FlowerService`, inject the `AnimalService` in the `AppComponent` class:
+`FlowerService` と同じパターンに従って、 `AppComponent` クラスに `AnimalService` を注入します。
 
 <docs-code header="src/app/app.component.ts" language="typescript" highlight="[4]">
 export class AppComponent {
@@ -562,10 +562,10 @@ export class AppComponent {
 }
 </docs-code>
 
-HELPFUL: You can leave all the `FlowerService` related code in place as it will allow a comparison with the `AnimalService`.
+HELPFUL: `FlowerService` に関連するコードはすべてそのままにしておくことができます。これにより、 `AnimalService` との比較が可能になります。
 
-Add a `viewProviders` array and inject the `AnimalService` in the `<app-child>` class, too, but give `emoji` a different value.
-Here, it has a value of dog <code>&#x1F436;</code>.
+`viewProviders` 配列を追加し、 `<app-child>` クラスにも `AnimalService` を注入しますが、 `emoji` に異なる値を与えます。
+ここでは、犬 <code>&#x1F436;</code> の値があります。
 
 <docs-code header="src/app/child.component.ts" language="typescript"
            highlight="[[7],[11]]">
@@ -573,31 +573,31 @@ Here, it has a value of dog <code>&#x1F436;</code>.
   selector: 'app-child',
   templateUrl: './child.component.html',
   styleUrls: ['./child.component.css'],
-  // provide services
+  // サービスを提供します
   providers: [{ provide: FlowerService, useValue: { emoji: '🌻' } }],
   viewProviders: [{ provide: AnimalService, useValue: { emoji: '🐶' } }]
 })
 export class ChildComponent {
-  // inject service
+  // サービスを注入します
   constructor( public flower: FlowerService, public animal: AnimalService) { }
 ...
 }
 </docs-code>
 
-Add bindings to the `ChildComponent` and the `AppComponent` templates.
-In the `ChildComponent` template, add the following binding:
+`ChildComponent` と `AppComponent` のテンプレートにバインディングを追加します。
+`ChildComponent` テンプレートに、次のバインディングを追加します。
 
 <docs-code header="src/app/child.component.html" language="html">
 <p>Emoji from AnimalService: {{animal.emoji}}</p>
 </docs-code>
 
-Additionally, add the same to the `AppComponent` template:
+さらに、 `AppComponent` テンプレートにも同じものを追加します。
 
 <docs-code header="src/app/app.component.html" language="html">
 <p>Emoji from AnimalService: {{animal.emoji}}</p>s
 </docs-code>
 
-Now you should see both values in the browser:
+これで、ブラウザに両方の値が表示されます。
 
 <docs-code hideCopy language="shell">
 
@@ -609,7 +609,7 @@ Emoji from AnimalService: &#x1F436;
 
 </docs-code>
 
-The logic tree for this example of `viewProviders` is as follows:
+この `viewProviders` の例の論理ツリーは次のとおりです。
 
 <docs-code language="html">
 
@@ -619,7 +619,7 @@ The logic tree for this example of `viewProviders` is as follows:
     <app-child>
       <#VIEW @Provide(AnimalService="&#x1F436;")
             @Inject(AnimalService=>"&#x1F436;")>
-       <!-- ^^using viewProviders means AnimalService is available in <#VIEW>-->
+       <!-- ^^viewProviders を使用すると、AnimalService は <#VIEW> で使用可能になります-->
        <p>Emoji from AnimalService: {{animal.emoji}} (&#x1F436;)</p>
       </#VIEW>
     </app-child>
@@ -628,18 +628,18 @@ The logic tree for this example of `viewProviders` is as follows:
 
 </docs-code>
 
-Just as with the `FlowerService` example, the `AnimalService` is provided in the `<app-child>` `@Component()` decorator.
-This means that since the injector first looks in the `ElementInjector` of the component, it finds the `AnimalService` value of dog <code>&#x1F436;</code>.
-It doesn't need to continue searching the `ElementInjector` tree, nor does it need to search the `ModuleInjector`.
+`FlowerService` の例と同様に、 `AnimalService` は `<app-child>` の `@Component()` デコレーターで提供されています。
+つまり、インジェクターは最初にコンポーネントの `ElementInjector` を調べるため、犬 <code>&#x1F436;</code> の `AnimalService` 値が見つかります。
+インジェクターは、 `ElementInjector` ツリーをさらに検索する必要も、 `ModuleInjector` を検索する必要もありません。
 
-### `providers` vs. `viewProviders`
+### `providers` と `viewProviders` の違い
 
-The `viewProviders` field is conceptually similar to `providers`, but there is one notable difference.
-Configured providers in `viewProviders` are not visible to projected content that ends up as a logical children of the component.
+`viewProviders` フィールドは、概念的には `providers` と似ていますが、1つの顕著な違いがあります。
+`viewProviders` で構成されたプロバイダーは、コンポーネントの論理的な子になる投影されたコンテンツには可視ではありません。
 
-To see the difference between using `providers` and `viewProviders`, add another component to the example and call it `InspectorComponent`.
-`InspectorComponent` will be a child of the `ChildComponent`.
-In `inspector.component.ts`, inject the `FlowerService` and `AnimalService` in the constructor:
+`providers` と `viewProviders` の違いを確認するために、別のコンポーネントを例に追加して、 `InspectorComponent` と呼びます。
+`InspectorComponent` は、 `ChildComponent` の子になります。
+`inspector.component.ts` で、コンストラクターに `FlowerService` と `AnimalService` を注入します。
 
 <docs-code header="src/app/inspector/inspector.component.ts" language="typescript">
 export class InspectorComponent {
@@ -647,15 +647,15 @@ export class InspectorComponent {
 }
 </docs-code>
 
-You do not need a `providers` or `viewProviders` array.
-Next, in `inspector.component.html`, add the same markup from previous components:
+`providers` または `viewProviders` 配列は必要ありません。
+次に、 `inspector.component.html` に、以前のコンポーネントと同じマークアップを追加します。
 
 <docs-code header="src/app/inspector/inspector.component.html" language="html">
 <p>Emoji from FlowerService: {{flower.emoji}}</p>
 <p>Emoji from AnimalService: {{animal.emoji}}</p>
 </docs-code>
 
-Remember to add the `InspectorComponent` to the `ChildComponent` `imports` array.
+`InspectorComponent` を `ChildComponent` の `imports` 配列に追加することを忘れないでください。
 
 <docs-code header="src/app/child/child.component.ts" language="typescript"
            highlight="[3]">
@@ -666,7 +666,7 @@ Remember to add the `InspectorComponent` to the `ChildComponent` `imports` array
 
 </docs-code>
 
-Next, add the following to `child.component.html`:
+次に、 `child.component.html` に次を追加します。
 
 <docs-code header="src/app/child/child.component.html" language="html"
            highlight="[3,9]">
@@ -681,9 +681,9 @@ Next, add the following to `child.component.html`:
 <app-inspector></app-inspector>
 </docs-code>
 
-`<ng-content>` allows you to project content, and `<app-inspector>` inside the `ChildComponent` template makes the `InspectorComponent` a child component of `ChildComponent`.
+`<ng-content>` を使用するとコンテンツを投影でき、 `ChildComponent` テンプレート内の `<app-inspector>` は、 `InspectorComponent` を `ChildComponent` の子コンポーネントにします。
 
-Next, add the following to `app.component.html` to take advantage of content projection.
+次に、コンテンツ投影を活用するために、 `app.component.html` に次を追加します。
 
 <docs-code header="src/app/app.component.html" language="html" highlight="[2]">
 <app-child>
@@ -691,7 +691,7 @@ Next, add the following to `app.component.html` to take advantage of content pro
 </app-child>
 </docs-code>
 
-The browser now renders the following, omitting the previous examples for brevity:
+これで、ブラウザには、以前の例は省略して、次のものがレンダリングされます。
 
 <docs-code hideCopy language="shell">
 ...
@@ -705,13 +705,13 @@ Emoji from AnimalService: &#x1F436;
 
 </docs-code>
 
-These four bindings demonstrate the difference between `providers` and `viewProviders`.
-Remember that the dog emoji <code>&#x1F436;</code> is declared inside the `<#VIEW>` of `ChildComponent` and isn't visible to the projected content.
-Instead, the projected content sees the whale <code>&#x1F433;</code>.
+これらの4つのバインディングは、 `providers` と `viewProviders` の違いを示しています。
+犬の絵文字 <code>&#x1F436;</code> は、 `ChildComponent` の `<#VIEW>` 内に宣言され、投影されたコンテンツには可視ではないことを覚えておいてください。
+代わりに、投影されたコンテンツには、クジラ <code>&#x1F433;</code> が表示されます。
 
-However, in the next output section though, the `InspectorComponent` is an actual child component of `ChildComponent`, `InspectorComponent` is inside the `<#VIEW>`, so when it asks for the `AnimalService`, it sees the dog <code>&#x1F436;</code>.
+ただし、次の出力セクションでは `InspectorComponent` は `ChildComponent` の実際の子コンポーネントです。そして `InspectorComponent` は `<#VIEW>` の内側にあるため、 `AnimalService` を要求すると、犬 <code>&#x1F436;</code> が表示されます。
 
-The `AnimalService` in the logical tree would look like this:
+論理ツリー内の `AnimalService` は、次のようになります。
 
 <docs-code language="html">
 
@@ -721,7 +721,7 @@ The `AnimalService` in the logical tree would look like this:
     <app-child>
       <#VIEW @Provide(AnimalService="&#x1F436;")
             @Inject(AnimalService=>"&#x1F436;")>
-        <!-- ^^using viewProviders means AnimalService is available in <#VIEW>-->
+        <!-- ^^viewProviders を使用すると、AnimalService は <#VIEW> で使用可能になります-->
         <p>Emoji from AnimalService: {{animal.emoji}} (&#x1F436;)</p>
 
         <div class="container">
@@ -743,25 +743,25 @@ The `AnimalService` in the logical tree would look like this:
 
 </docs-code>
 
-The projected content of `<app-inspector>` sees the whale <code>&#x1F433;</code>, not the dog <code>&#x1F436;</code>, because the dog <code>&#x1F436;</code> is inside the `<app-child>` `<#VIEW>`.
-The `<app-inspector>` can only see the dog <code>&#x1F436;</code> if it is also within the `<#VIEW>`.
+`<app-inspector>` の投影されたコンテンツには、クジラ <code>&#x1F433;</code> が表示され、犬 <code>&#x1F436;</code> は表示されません。これは、犬 <code>&#x1F436;</code> が `<app-child>` の `<#VIEW>` の内側にあるためです。
+`<app-inspector>` は、 `<#VIEW>` の内側にある場合にのみ、犬 <code>&#x1F436;</code> を表示できます。
 
-### Visibility of provided tokens
+### 提供されたトークンの可視性
 
-Visibility decorators influence where the search for the injection token begins and ends in the logic tree.
-To do this, place visibility decorators at the point of injection, that is, the `constructor()`, rather than at a point of declaration.
+可視性デコレーターは、論理ツリー内でインジェクショントークンの検索を開始する場所と終了する場所を制御します。
+これを行うには、可視性デコレーターを注入ポイント、つまり `constructor()` に配置し、宣言ポイントに配置しないでください。
 
-To alter where the injector starts looking for `FlowerService`, add `@SkipSelf()` to the `<app-child>` `@Inject` declaration where `FlowerService` is injected.
-This declaration is in the `<app-child>` constructor as shown in `child.component.ts`:
+インジェクターが `FlowerService` の検索を開始する場所を変更するには、 `<app-child>` の `@Inject` 宣言に `@SkipSelf()` を追加します。
+この宣言は、 `child.component.ts` に示すように、 `<app-child>` のコンストラクターにあります。
 
 <docs-code language="typescript">
 constructor(@SkipSelf() public flower: FlowerService) { }
 </docs-code>
 
-With `@SkipSelf()`, the `<app-child>` injector doesn't look to itself for the `FlowerService`.
-Instead, the injector starts looking for the `FlowerService` at the `ElementInjector` of the `<app-root>`, where it finds nothing.
-Then, it goes back to the `<app-child>` `ModuleInjector` and finds the red hibiscus <code>&#x1F33A;</code> value, which is available because `<app-child>` and `<app-root>` share the same `ModuleInjector`.
-The UI renders the following:
+`@SkipSelf()` を使用すると、 `<app-child>` インジェクターは、 `FlowerService` を自身で検索しません。
+代わりに、インジェクターは `<app-root>` の `ElementInjector` で `FlowerService` の検索を開始し、何も見つかりません。
+次に、 `<app-child>` の `ModuleInjector` に戻り、 `<app-child>` と `<app-root>` が同じ `ModuleInjector` を共有しているため、赤いハイビスカス <code>&#x1F33A;</code> 値が見つかります。
+UIには次のように表示されます。
 
 <docs-code hideCopy language="shell">
 
@@ -769,7 +769,7 @@ Emoji from FlowerService: &#x1F33A;
 
 </docs-code>
 
-In a logical tree, this same idea might look like this:
+論理ツリーでは、この同じ考え方は次のようになります。
 
 <docs-code language="html">
 
@@ -778,7 +778,7 @@ In a logical tree, this same idea might look like this:
   <#VIEW>
     <app-child @Provide(FlowerService="&#x1F33B;")>
       <#VIEW @Inject(FlowerService, SkipSelf)=>"&#x1F33A;">
-        <!-- With SkipSelf, the injector looks to the next injector up the tree (app-root) -->
+        <!-- SkipSelf を使用すると、インジェクターはツリー上の次のインジェクター（app-root）を調べます -->
       </#VIEW>
     </app-child>
   </#VIEW>
@@ -786,18 +786,18 @@ In a logical tree, this same idea might look like this:
 
 </docs-code>
 
-Though `<app-child>` provides the sunflower <code>&#x1F33B;</code>, the application renders the red hibiscus <code>&#x1F33A;</code> because `@SkipSelf()` causes the current injector (`app-child`) to skip itself and look to its parent.
+`<app-child>` はひまわり <code>&#x1F33B;</code> を提供しますが、アプリケーションは赤いハイビスカス <code>&#x1F33A;</code> をレンダリングします。これは、 `@SkipSelf()` によって現在のインジェクター（`app-child`）が自身をスキップして親を調べるためです。
 
-If you now add `@Host()` (in addition to the `@SkipSelf()`), the result will be `null`.
-This is because `@Host()` limits the upper bound of the search to the `app-child` `<#VIEW>`.
-Here's the idea in the logical tree:
+`@Host()` を追加すると（`@SkipSelf()` に加えて）、結果は `null` になります。
+これは、 `@Host()` が検索の上限を `<app-child>` の `<#VIEW>` に制限するためです。
+論理ツリーでの考え方は次のとおりです。
 
 <docs-code language="html">
 
 <app-root @ApplicationConfig
         @Inject(FlowerService) flower=>"&#x1F33A;">
-  <#VIEW> <!-- end search here with null-->
-    <app-child @Provide(FlowerService="&#x1F33B;")> <!-- start search here -->
+  <#VIEW> <!-- ここで検索を終了して null を返します-->
+    <app-child @Provide(FlowerService="&#x1F33B;")> <!-- ここで検索を開始します -->
       <#VIEW @Inject(FlowerService, @SkipSelf, @Host, @Optional)=>null>
       </#VIEW>
       </app-parent>
@@ -806,15 +806,15 @@ Here's the idea in the logical tree:
 
 </docs-code>
 
-Here, the services and their values are the same, but `@Host()` stops the injector from looking any further than the `<#VIEW>` for `FlowerService`, so it doesn't find it and returns `null`.
+ここではサービスとその値は同じですが、 `@Host()` によってインジェクターは `<#VIEW>` より先を `FlowerService` について検索できなくなるため、見つからずに `null` を返します。
 
-### `@SkipSelf()` and `viewProviders`
+### `@SkipSelf()` と `viewProviders`
 
-Remember, `<app-child>` provides the `AnimalService` in the `viewProviders` array with the value of dog <code>&#x1F436;</code>.
-Because the injector has only to look at the `ElementInjector` of the `<app-child>` for the `AnimalService`, it never sees the whale <code>&#x1F433;</code>.
+覚えておいてください。 `<app-child>` は、 `viewProviders` 配列で `AnimalService` を提供し、その値は犬 <code>&#x1F436;</code> です。
+インジェクターは、 `<app-child>` の `ElementInjector` を `AnimalService` について調べるだけなので、クジラ <code>&#x1F433;</code> は見えません。
 
-As in the `FlowerService` example, if you add `@SkipSelf()` to the constructor for the `AnimalService`, the injector won't look in the  `ElementInjector` of the current `<app-child>` for the `AnimalService`.
-Instead, the injector will begin at the `<app-root>` `ElementInjector`.
+`FlowerService` の例と同様に、コンストラクターに `@SkipSelf()` を追加すると、インジェクターは現在の `<app-child>` の `ElementInjector` を `AnimalService` について検索しません。
+代わりに、インジェクターは `<app-root>` の `ElementInjector` で検索を開始します。
 
 <docs-code language="typescript" highlight="[6]">
 @Component({
@@ -827,17 +827,17 @@ Instead, the injector will begin at the `<app-root>` `ElementInjector`.
 })
 </docs-code>
 
-The logical tree looks like this with `@SkipSelf()` in `<app-child>`:
+論理ツリーは、 `<app-child>` に `@SkipSelf()` がある場合、次のようになります。
 
 <docs-code language="html">
 
 <app-root @ApplicationConfig
           @Inject(AnimalService=>"&#x1F433;")>
-  <#VIEW><!-- search begins here -->
+  <#VIEW><!-- 検索はここで開始します -->
     <app-child>
       <#VIEW @Provide(AnimalService="&#x1F436;")
              @Inject(AnimalService, SkipSelf=>"&#x1F433;")>
-        <!--Add @SkipSelf -->
+        <!--@SkipSelf を追加します -->
       </#VIEW>
     </app-child>
   </#VIEW>
@@ -845,13 +845,13 @@ The logical tree looks like this with `@SkipSelf()` in `<app-child>`:
 
 </docs-code>
 
-With `@SkipSelf()` in the `<app-child>`, the injector begins its search for the `AnimalService` in the `<app-root>` `ElementInjector` and finds whale <code>&#x1F433;</code>.
+`<app-child>` に `@SkipSelf()` があると、インジェクターは `<app-root>` の `ElementInjector` で `AnimalService` の検索を開始し、クジラ <code>&#x1F433;</code> を見つけます。
 
-### `@Host()` and `viewProviders`
+### `@Host()` と `viewProviders`
 
-If you just use `@Host()` for the injection of `AnimalService`, the result is dog <code>&#x1F436;</code> because the injector finds the `AnimalService` in the `<app-child>` `<#VIEW>` itself.
-The `ChildComponent` configures the `viewProviders` so that the dog emoji is provided as `AnimalService` value.
-You can also see `@Host()` in the constructor:
+`@Host()` を単独で使用した場合、結果は犬 <code>&#x1F436;</code> になります。なぜなら、インジェクターは `<app-child>` の `<#VIEW>` 自体で `AnimalService` を見つけるためです。
+`ChildComponent` は、 `viewProviders` を構成して、犬の絵文字が `AnimalService` 値として提供されるようにします。
+また、コンストラクターに `@Host()` があることもわかります。
 
 <docs-code language="typescript" highlight="[[6],[10]]">
 @Component({
@@ -867,7 +867,7 @@ export class ChildComponent {
 }
 </docs-code>
 
-`@Host()` causes the injector to look until it encounters the edge of the `<#VIEW>`.
+`@Host()` によって、インジェクターは `<#VIEW>` の端に出会うまで検索します。
 
 <docs-code language="html">
 
@@ -876,7 +876,7 @@ export class ChildComponent {
   <#VIEW>
     <app-child>
       <#VIEW @Provide(AnimalService="&#x1F436;")
-             @Inject(AnimalService, @Host=>"&#x1F436;")> <!-- @Host stops search here -->
+             @Inject(AnimalService, @Host=>"&#x1F436;")> <!-- @Host はここで検索を停止します -->
       </#VIEW>
     </app-child>
   </#VIEW>
@@ -884,7 +884,7 @@ export class ChildComponent {
 
 </docs-code>
 
-Add a `viewProviders` array with a third animal, hedgehog <code>&#x1F994;</code>, to the `app.component.ts` `@Component()` metadata:
+3番目の動物、ハリネズミ <code>&#x1F994;</code> を含む `viewProviders` 配列を、 `app.component.ts` の `@Component()` メタデータに追加します。
 
 <docs-code language="typescript" highlight="[7]">
 @Component({
@@ -899,8 +899,8 @@ Add a `viewProviders` array with a third animal, hedgehog <code>&#x1F994;</code>
 
 </docs-code>
 
-Next, add `@SkipSelf()` along with `@Host()` to the constructor for the `AnimalService` injection in `child.component.ts`.
-Here are `@Host()` and `@SkipSelf()` in the `<app-child>` constructor:
+次に、 `child.component.ts` で `AnimalService` の注入のコンストラクターに `@SkipSelf()` と `@Host()` を追加します。
+以下は、 `<app-child>` のコンストラクターにある `@Host()` と `@SkipSelf()` です。
 
 <docs-code language="typescript" highlight="[4]">
 export class ChildComponent {
@@ -911,16 +911,16 @@ export class ChildComponent {
 
 </docs-code>
 
-<!-- TODO: This requires a rework. It seems not well explained what `viewProviders`/`injectors` is here
-  and how `@Host()` works.
- -->
+<!-- TODO: これは作り直す必要があります。
+  ここで `viewProviders`/`injectors` と `@Host()` の仕組みが十分に説明されていないようです。
+  -->
 
-When `@Host()` and `@SkipSelf()` were applied to the `FlowerService`, which is in the `providers` array, the result was `null` because `@SkipSelf()` starts its search in the `<app-child>` injector, but `@Host()` stops searching at `<#VIEW>` —where there is no `FlowerService`
-In the logical tree, you can see that the `FlowerService` is visible in `<app-child>`, not its `<#VIEW>`.
+`@Host()` と `@SkipSelf()` が `providers` 配列にある `FlowerService` に適用された場合、結果は `null` になりました。これは、 `@SkipSelf()` が `<app-child>` インジェクターで検索を開始しますが、 `@Host()` は `<#VIEW>` での検索を停止するためです。そこには `FlowerService` はありません。
+論理ツリーでは、 `FlowerService` は `<app-child>` で可視であり、 `<#VIEW>` では可視ではないことがわかります。
 
-However, the `AnimalService`, which is provided in the `AppComponent` `viewProviders` array, is visible.
+ただし、 `AppComponent` の `viewProviders` 配列で提供されている `AnimalService` は可視です。
 
-The logical tree representation shows why this is:
+論理ツリーの表現は、これが理由を示しています。
 
 <docs-code language="html">
 
@@ -928,11 +928,11 @@ The logical tree representation shows why this is:
         @Inject(AnimalService=>"&#x1F433;")>
   <#VIEW @Provide(AnimalService="&#x1F994;")
          @Inject(AnimalService, @Optional)=>"&#x1F994;">
-    <!-- ^^@SkipSelf() starts here,  @Host() stops here^^ -->
+    <!-- ^^@SkipSelf() はここで開始し、 @Host() はここで停止します^^ -->
     <app-child>
       <#VIEW @Provide(AnimalService="&#x1F436;")
              @Inject(AnimalService, @SkipSelf, @Host, @Optional)=>"&#x1F994;">
-               <!-- Add @SkipSelf ^^-->
+               <!-- @SkipSelf を追加します ^^-->
       </#VIEW>
       </app-child>
   </#VIEW>
@@ -940,23 +940,23 @@ The logical tree representation shows why this is:
 
 </docs-code>
 
-`@SkipSelf()`, causes the injector to start its search for the `AnimalService` at the `<app-root>`, not the `<app-child>`, where the request originates, and `@Host()` stops the search at the `<app-root>` `<#VIEW>`.
-Since `AnimalService` is provided by way of the `viewProviders` array, the injector finds hedgehog <code>&#x1F994;</code> in the `<#VIEW>`.
+`@SkipSelf()` は、インジェクターが `AnimalService` の検索を要求が発生した `<app-child>` ではなく、 `<app-root>` で開始するように指示し、 `@Host()` は `<app-root>` の `<#VIEW>` で検索を停止します。
+`AnimalService` は `viewProviders` 配列を介して提供されるため、インジェクターは `<#VIEW>` でハリネズミ <code>&#x1F994;</code> を見つけます。
 
-## Example: `ElementInjector` use cases
+## 例： `ElementInjector` のユースケース
 
-The ability to configure one or more providers at different levels opens up useful possibilities.
+さまざまなレベルで1つ以上のプロバイダーを構成する機能により、便利な可能性が開かれます。
 
-### Scenario: service isolation
+### シナリオ：サービスの分離
 
-Architectural reasons may lead you to restrict access to a service to the application domain where it belongs.
-For example, consider we build a `VillainsListComponent` that displays a list of villains.
-It gets those villains from a `VillainsService`.
+アーキテクチャ上の理由から、サービスへのアクセスを属するアプリケーションドメインに制限する必要がある場合があります。
+たとえば、悪役のリストを表示する `VillainsListComponent` を構築するとします。
+この悪役は、 `VillainsService` から取得されます。
 
-If you provide `VillainsService` in the root `AppModule`, it will make `VillainsService` visible everywhere in the application.
-If you later modify the `VillainsService`, you could break something in other components that started depending this service by accident.
+`VillainsService` をルートの `AppModule` で提供すると、 `VillainsService` がアプリケーションのすべての場所で可視になります。
+後で `VillainsService` を変更した場合、誤ってこのサービスに依存し始めた他のコンポーネントで何かが壊れる可能性があります。
 
-Instead, you should provide the `VillainsService` in the `providers` metadata of the `VillainsListComponent` like this:
+代わりに、次のように `VillainsListComponent` の `providers` メタデータで `VillainsService` を提供する必要があります。
 
 <docs-code header="src/app/villains-list.component.ts (metadata)" language="typescript"
            highlight="[4]">
@@ -968,34 +968,34 @@ Instead, you should provide the `VillainsService` in the `providers` metadata of
 export class VillainsListComponent {}
 </docs-code>
 
-By providing `VillainsService` in the `VillainsListComponent` metadata and nowhere else, the service becomes available only in the `VillainsListComponent` and its subcomponent tree.
+`VillainsService` を `VillainsListComponent` メタデータで提供し、他の場所では提供しないと、サービスは `VillainsListComponent` とそのサブコンポーネントツリーのみに使用可能になります。
 
-`VillainService` is a singleton with respect to `VillainsListComponent` because that is where it is declared.
-As long as `VillainsListComponent` does not get destroyed it will be the same instance of `VillainService` but if there are multiple instances of `VillainsListComponent`, then each instance of `VillainsListComponent` will have its own instance of `VillainService`.
+`VillainService` は、 `VillainsListComponent` に対してシングルトンです。なぜなら、それが宣言されている場所だからです。
+`VillainsListComponent` が破棄されない限り `VillainService` のインスタンスは同じです。ただし `VillainsListComponent` のインスタンスが複数ある場合、 `VillainsListComponent` の各インスタンスには、独自の `VillainService` インスタンスが1つずつあります。
 
-### Scenario: multiple edit sessions
+### シナリオ：複数の編集セッション
 
-Many applications allow users to work on several open tasks at the same time.
-For example, in a tax preparation application, the preparer could be working on several tax returns, switching from one to the other throughout the day.
+多くのアプリケーションでは、ユーザーは同時に複数のオープンタスクで作業できます。
+たとえば、税務申告の作成アプリケーションでは、作成者は複数の税務申告で作業し、1日を通してそれらを切り替えることができます。
 
-To demonstrate that scenario, imagine a `HeroListComponent` that displays a list of super heroes.
+そのシナリオを示すために、スーパーヒーローのリストを表示する `HeroListComponent` を考えてみてください。
 
-To open a hero's tax return, the preparer clicks on a hero name, which opens a component for editing that return.
-Each selected hero tax return opens in its own component and multiple returns can be open at the same time.
+ヒーローの税務申告を開くために、作成者はヒーローの名前をクリックすると、その申告を編集するためのコンポーネントが開きます。
+選択したヒーローの税務申告は、それぞれ独自のコンポーネントで開き、複数の申告を同時に開くことができます。
 
-Each tax return component has the following characteristics:
+各税務申告コンポーネントには、次の機能があります。
 
-* Is its own tax return editing session
-* Can change a tax return without affecting a return in another component
-* Has the ability to save the changes to its tax return or cancel them
+* 独自の税務申告の編集セッションを持ちます
+* 別のコンポーネントの申告に影響を与えずに税務申告を変更できます
+* 税務申告の変更を保存するか、キャンセルする機能があります
 
-Suppose that the `HeroTaxReturnComponent` had logic to manage and restore changes.
-That would be a straightforward task for a hero tax return.
-In the real world, with a rich tax return data model, the change management would be tricky.
-You could delegate that management to a helper service, as this example does.
+`HeroTaxReturnComponent` に、変更を管理および復元するためのロジックがあるとします。
+これは、ヒーローの税務申告にとっては簡単なタスクです。
+現実世界では、豊富な税務申告データモデルでは、変更管理が複雑になります。
+この例のように、この管理をヘルパーサービスに委任できます。
 
-The `HeroTaxReturnService` caches a single `HeroTaxReturn`, tracks changes to that return, and can save or restore it.
-It also delegates to the application-wide singleton `HeroService`, which it gets by injection.
+`HeroTaxReturnService` は、単一の `HeroTaxReturn` をキャッシュし、その申告への変更を追跡し、保存または復元できます。
+また、注入によって取得したアプリケーション全体のシングルトン `HeroService` に委任します。
 
 <docs-code header="src/app/hero-tax-return.service.ts" language="typescript">
 import { Injectable } from '@angular/core';
@@ -1029,7 +1029,7 @@ export class HeroTaxReturnService {
 }
 </docs-code>
 
-Here is the `HeroTaxReturnComponent` that makes use of `HeroTaxReturnService`.
+以下は、 `HeroTaxReturnService` を使用する `HeroTaxReturnComponent` です。
 
 <docs-code header="src/app/hero-tax-return.component.ts" language="typescript">
 import { Component, EventEmitter, Input, Output } from '@angular/core';
@@ -1077,39 +1077,39 @@ export class HeroTaxReturnComponent {
 }
 </docs-code>
 
-The _tax-return-to-edit_ arrives by way of the `@Input()` property, which is implemented with getters and setters.
-The setter initializes the component's own instance of the `HeroTaxReturnService` with the incoming return.
-The getter always returns what that service says is the current state of the hero.
-The component also asks the service to save and restore this tax return.
+_編集対象の税務申告_ は、 `@Input()` プロパティを介して到着します。これは、ゲッターとセッターで実装されています。
+セッターは、コンポーネント自身の `HeroTaxReturnService` インスタンスを、受信した申告で初期化します。
+ゲッターは常に、そのサービスがヒーローの現在の状態であると判断したものを返します。
+コンポーネントは、この税務申告を保存および復元することもサービスに要求します。
 
-This won't work if the service is an application-wide singleton.
-Every component would share the same service instance, and each component would overwrite the tax return that belonged to another hero.
+これは、サービスがアプリケーション全体のシングルトンである場合に機能しません。
+すべてのコンポーネントは同じサービスインスタンスを共有し、各コンポーネントは別のヒーローに属する税務申告を上書きします。
 
-To prevent this, configure the component-level injector of `HeroTaxReturnComponent` to provide the service, using the `providers` property in the component metadata.
+これを防ぐために、コンポーネントレベルのインジェクター `HeroTaxReturnComponent` を構成して、コンポーネントメタデータの `providers` プロパティを使用してサービスを提供します。
 
 <docs-code header="src/app/hero-tax-return.component.ts (providers)" language="typescript">
 providers: [HeroTaxReturnService]
 </docs-code>
 
-The `HeroTaxReturnComponent` has its own provider of the `HeroTaxReturnService`.
-Recall that every component _instance_ has its own injector.
-Providing the service at the component level ensures that _every_ instance of the component gets a private instance of the service. This makes sure that no tax return gets overwritten.
+`HeroTaxReturnComponent` には、 `HeroTaxReturnService` の独自の提供者がいます。
+覚えておいてください。すべてのコンポーネントの _インスタンス_ には、独自のインジェクターがあります。
+コンポーネントレベルでサービスを提供すると、コンポーネントの _すべての_ インスタンスは、サービスのプライベートインスタンスを1つずつ取得することが保証されます。これにより、税務申告が上書きされないようにします。
 
-HELPFUL: The rest of the scenario code relies on other Angular features and techniques that you can learn about elsewhere in the documentation.
+HELPFUL: シナリオコードの残りは、ドキュメントの他の場所で学習できる他のAngular機能とテクニックに依存しています。
 
-### Scenario: specialized providers
+### シナリオ：特殊なプロバイダー
 
-Another reason to provide a service again at another level is to substitute a _more specialized_ implementation of that service, deeper in the component tree.
+別のレベルでサービスを再度提供するもう1つの理由は、コンポーネントツリーのさらに深い場所で、そのサービスの _より特殊な_ 実装を置き換えるためです。
 
-For example, consider a `Car` component that includes tire service information and depends on other services to provide more details about the car.
+たとえば、タイヤサービスの情報を含み、他のサービスに依存して車の詳細情報を提供する `Car` コンポーネントを検討してください。
 
-The root injector, marked as (A), uses _generic_ providers for details about `CarService` and `EngineService`.
+ルートインジェクター（(A) とマーク付け）は、 `CarService` と `EngineService` について、_汎用的な_ プロバイダーを使用します。
 
-1. `Car` component (A).  Component (A) displays tire service data about a car and specifies generic services to provide more information about the car.
+1. `Car` コンポーネント (A)。コンポーネント (A) は、車のタイヤサービスデータを表示し、車の詳細情報を提供するための汎用サービスを指定します。
 
-2. Child component (B). Component (B) defines its own, _specialized_ providers for `CarService` and `EngineService` that have special capabilities suitable for what's going on in component (B).
+2. 子コンポーネント (B)。コンポーネント (B) は、コンポーネント (B) で行われていることに適した特別な機能を持つ、 `CarService` と `EngineService` の独自の _特殊な_ プロバイダーを定義します。
 
-3. Child component (C) as a child of Component (B). Component (C) defines its own, even _more specialized_ provider for `CarService`.
+3. コンポーネント (B) の子である子コンポーネント (C)。コンポーネント (C) は、 `CarService` の独自の、さらに _特殊な_ プロバイダーを定義します。
 
 ```mermaid
 graph TD;
@@ -1126,13 +1126,13 @@ classDef noShadow filter:none
 class COMPONENT_A,COMPONENT_B,COMPONENT_C noShadow
 ```
 
-Behind the scenes, each component sets up its own injector with zero, one, or more providers defined for that component itself.
+裏側では、各コンポーネントはコンポーネント自体に定義された、0、1または複数のプロバイダーで独自のインジェクターを設定します。
 
-When you resolve an instance of `Car` at the deepest component (C), its injector produces:
+最も深いコンポーネント (C) で `Car` のインスタンスを解決すると、そのインジェクターは次を生成します。
 
-* An instance of `Car` resolved by injector (C)
-* An `Engine` resolved by injector (B)
-* Its `Tires` resolved by the root injector (A).
+* インジェクター (C) によって解決された `Car` のインスタンス
+* インジェクター (B) によって解決された `Engine`
+* ルートインジェクター (A) によって解決された `Tires`。
 
 ```mermaid
 graph BT;
@@ -1173,8 +1173,8 @@ style tires fill:#BDD7EE,color:#000
 style RootInjector fill:#BDD7EE,color:#000
 ```
 
-## More on dependency injection
+## 依存性の注入の詳細
 
 <docs-pill-row>
-  <docs-pill href="/guide/di/dependency-injection-providers" title="DI Providers"/>
+  <docs-pill href="/guide/di/dependency-injection-providers" title="DIプロバイダー"/>
 </docs-pill-row>
diff --git a/prh.yml b/prh.yml
index f45d3f196f..d7deb53b5f 100644
--- a/prh.yml
+++ b/prh.yml
@@ -5,7 +5,10 @@ rules:
   # 言い換え
 
   - expected: 依存性の注入
-    pattern: 依存性注入
+    pattern: 
+      - 依存性注入
+      - 依存関係の注入
+      - 依存関係注入
 
   - expected: 依存性を注入し
     pattern: 依存注入し

From 609eaf935d3b88a595920b724fbb7064ecc4af1d Mon Sep 17 00:00:00 2001
From: Suguru Inatomi <suguru.inatomi@gmail.com>
Date: Sat, 20 Jul 2024 14:17:08 +0900
Subject: [PATCH 3/3] chore: translate large content by splitting

---
 tools/lib/fsutils.ts |   7 +++
 tools/translate.ts   | 115 ++++++++++++++++++++++++++++++-------------
 2 files changed, 88 insertions(+), 34 deletions(-)

diff --git a/tools/lib/fsutils.ts b/tools/lib/fsutils.ts
index 1483d5a1dc..0502036211 100644
--- a/tools/lib/fsutils.ts
+++ b/tools/lib/fsutils.ts
@@ -1,3 +1,4 @@
+import { $ } from 'execa';
 import { globby } from 'globby';
 import { access, cp, readFile, rm, writeFile } from 'node:fs/promises';
 
@@ -33,3 +34,9 @@ export async function rename(oldPath: string, newPath: string) {
   await cp(oldPath, newPath);
   await rm(oldPath);
 }
+
+export async function getLineCount(path: string) {
+  return $`wc -l ${path}`.then(({ stdout }) => {
+    return parseInt(stdout.trim().split(' ')[0]);
+  });
+}
diff --git a/tools/translate.ts b/tools/translate.ts
index 27e38e90d8..5a8af38954 100644
--- a/tools/translate.ts
+++ b/tools/translate.ts
@@ -13,7 +13,7 @@ import assert from 'node:assert';
 import { stat, writeFile } from 'node:fs/promises';
 import { resolve } from 'node:path';
 import { parseArgs } from 'node:util';
-import { glob } from './lib/fsutils';
+import { getLineCount, glob } from './lib/fsutils';
 import { rootDir } from './lib/workspace';
 
 const apiKey = process.env.GOOGLE_API_KEY;
@@ -23,13 +23,13 @@ const fileManager = new GoogleAIFileManager(apiKey);
 const model = genAI.getGenerativeModel({
   model: 'gemini-1.5-flash',
   systemInstruction: `
-あなたはWebフロントエンドに関する技術文書の翻訳アシスタントです。
-Markdownファイルを受け取り、英語を日本語に翻訳した結果を出力してください。
-翻訳作業は以下のルールを遵守してください。
-- 元のMarkdownの文書構造を維持してください。
+あなたは技術文書の翻訳アシスタントです。
+Markdown形式のテキストを受け取り、日本語に翻訳してください。以下のルールを遵守してください。
+- 元のMarkdownの改行やインデントの構造を維持してください。
 - 内容の説明は含めず、翻訳結果のみを出力してください。
 - コードブロックの中身は翻訳しないでください。
-- "TIP: ", "HELPFUL: ", "IMPORTANT: "など、ヒントや注意書きを示すプレフィックスは変更しないでください。
+- 行頭の特別なプレフィックス [TIP,HELPFUL,IMPORTANT,NOTE,QUESTION,TLDR,CRITICAL] は翻訳しないでください。
+- prh.yml は日本語の校正ルールが書かれたYAMLファイルです。このルールに従って翻訳してください。
 `.trim(),
 });
 
@@ -81,35 +81,82 @@ async function translateFile(file: string, forceWrite = false) {
     displayName: `content.md`,
   });
   // Execute translation
-  const result = await model.generateContentStream([
-    {
-      fileData: {
-        mimeType: contentFile.file.mimeType,
-        fileUri: contentFile.file.uri,
-      },
-    },
-    {
-      fileData: {
-        mimeType: prhFile.file.mimeType,
-        fileUri: prhFile.file.uri,
-      },
-    },
-    `content.md を日本語に翻訳してください。`,
-    `prh.yml は日本語の校正ルールが書かれたYAMLファイルです。ルールに従って翻訳後のテキストを修正してください。`,
-  ]);
-  // Show translation result
-  process.stdout.write('\n----\n');
-  const chunks: string[] = [];
-  for await (const chunk of result.stream) {
-    const text = chunk.text();
-    chunks.push(text);
-    process.stdout.write(text);
-  }
-  process.stdout.write('\n----\n');
+  consola.info(`翻訳中...`);
+  const lineCount = await getLineCount(file);
+  if (lineCount < 500) {
+    const translatedContent = await model
+      .generateContent([
+        {
+          fileData: {
+            mimeType: prhFile.file.mimeType,
+            fileUri: prhFile.file.uri,
+          },
+        },
+        {
+          fileData: {
+            mimeType: contentFile.file.mimeType,
+            fileUri: contentFile.file.uri,
+          },
+        },
+        `content.md を日本語に翻訳してください。`,
+      ])
+      .then(({ response }) => response.text());
+    await writeTranslatedContent(file, translatedContent, forceWrite);
+  } else {
+    consola.warn(
+      `ファイルが大きいため、いくつかの断片に分割して翻訳されます。翻訳後の整合性に注意してください。`
+    );
+    const translationChunks: string[] = [];
+    const chat = await model.startChat({ history: [] });
+    let count = 1;
+    const maxCount = Math.ceil(lineCount / 100); // 100行ごとに分割した回数より多くなった場合はエラー
+    let lastTranslationChunk = await chat
+      .sendMessage([
+        {
+          fileData: {
+            mimeType: prhFile.file.mimeType,
+            fileUri: prhFile.file.uri,
+          },
+        },
+        {
+          fileData: {
+            mimeType: contentFile.file.mimeType,
+            fileUri: contentFile.file.uri,
+          },
+        },
+        `content.md を日本語に翻訳してください。翻訳結果のテキストを100行ずつに分割して。その1番目の部分を出力してください。`,
+      ])
+      .then(({ response }) => response.text().trim());
+    while (count < maxCount) {
+      consola.log(`\n---- 翻訳結果 (${count}) ----\n`);
+      consola.log(lastTranslationChunk);
+      translationChunks.push(lastTranslationChunk);
+      translationChunks.push(`<!-- TRANSLATION_CHUNK -->`);
 
-  consola.success('翻訳完了');
-  const translatedContent = chunks.join('');
+      // Continue translation
+      count++;
+      const chunk = await chat
+        .sendMessage(
+          `続けて、翻訳結果の${count}番目の部分を出力してください。${count}番目が存在しなければ「EOF」と出力してください`
+        )
+        .then(({ response }) => response.text().trim());
+      // Abort if infinite loop detected
+      if (chunk === 'EOF' || lastTranslationChunk === chunk) {
+        break;
+      }
+      lastTranslationChunk = chunk;
+    }
+    consola.success('翻訳完了');
+    const translatedContent = translationChunks.join('\n');
+    await writeTranslatedContent(file, translatedContent, forceWrite);
+  }
+}
 
+async function writeTranslatedContent(
+  file: string,
+  content: string,
+  forceWrite = false
+) {
   // 元のファイル拡張子が .en.* の場合は .* として保存する
   const outFilePath = file.replace(/\.en\.([^.]+)$/, '.$1');
   const save =
@@ -121,7 +168,7 @@ async function translateFile(file: string, forceWrite = false) {
   if (!save) {
     return;
   }
-  await writeFile(outFilePath, translatedContent);
+  await writeFile(outFilePath, content);
   consola.success(`保存しました`);
 }