feat: align tutorial/part-2 titles with index and recap

guides/tutorial/part-2/ember-data.md

@@ -6,11 +6,11 @@ In this chapter, we will work on removing some code duplication in our route han
 
 During this refactor, you will learn about:
 
-- Ember Data models
-- Testing models
-- Loading models in routes
-- The Ember Data store
-- Working with adapters and serializers
+- Les modèles Ember Data
+- Tester les modèles
+- Charger un modèle dans une route
+- Le _store_ d'Ember Data
+- Travailler avec des adaptateurs et des sérialiseurs
 
 ## What is Ember Data?
 
@@ -286,7 +286,7 @@ Wow... that removed a lot of code! This is all possible thanks to the power of c
 
 As mentioned above, Ember Data provides a `store` service, which we can inject into our route using the `@service store;` declaration, making the Ember Data store available as `this.store`. It provides the `find` and `findAll` methods for loading records. Specifically, the [`findRecord` method](../../../models/finding-records/#toc_retrieving-a-single-record) takes a model type (`rental` in our case) and a model ID (for us, that would be `params.rental_id` from the URL) as arguments and fetches a single record from the store. On the other hand, the [`findAll` method](../../../models/finding-records/#toc_retrieving-multiple-records) takes the model type as an argument and fetches all records of that type from the store.
 
-The Ember Data store acts as a kind of intermediary between our app and the server; it does many important things, including caching the responses that were fetched from the server. If we request some records (instances of model classes) that we had _already_ fetched from the server in the past, Ember Data's store ensures that we can access the records immediately, without having to fetch them again unnecessarily and wait for the server to respond. But, if we don't already have that response cached in our store, then it will go off and fetches it from the server. Pretty nice, right?
+Le _store_ d'Ember Data acts as a kind of intermediary between our app and the server; it does many important things, including caching the responses that were fetched from the server. If we request some records (instances of model classes) that we had _already_ fetched from the server in the past, Ember Data's store ensures that we can access the records immediately, without having to fetch them again unnecessarily and wait for the server to respond. But, if we don't already have that response cached in our store, then it will go off and fetches it from the server. Pretty nice, right?
 
 That's a lot of theory, but is this going to work in our app? Let's run the tests and find out!
 
@@ -301,7 +301,7 @@ Looking at the failure messages, the problem appears to be that the store went t
 
 Hm, okay, so we have to teach Ember Data to fetch data from the correct location. But how does Ember Data know how to fetch data from our server in the first place?
 
-## Working with Adapters and Serializers
+## Travailler avec des adaptateurs et des sérialiseurs
 
 Ember Data uses an _[adapter](../../../models/customizing-adapters/)_ and _[serializer](../../../models/customizing-serializers/)_ architecture. Adapters deal with _how_ and _where_ Ember Data should fetch data from your servers, such as whether to use HTTP, HTTPS, WebSockets or local storage, as well as the URLs, headers and parameters to use for these requests. On the other hand, serializers are in charge of converting the data returned by the server into a format Ember Data can understand.
 

guides/tutorial/part-2/provider-components.md

@@ -8,10 +8,10 @@ In this chapter, we'll work on adding a new search feature, and refactor our `in
 
 During this refactor, you will learn about:
 
-- Using Ember's built-in `<Input>` component
-- The provider component pattern
-- Using block parameters when invoking components
-- Yielding data to caller components
+- Utiliser le composant `<Input>` d'Ember
+- Le patron de conception _provider component_
+- Utiliser des paramètres de bloc en invoquant un composant
+- Retourner des données au composant appelant
 
 ## Add input
 
@@ -245,7 +245,7 @@ Ember's `<Input>` component is pretty neat; it will wire up things behind the sc
   </div>
 </div>
 
-## Adding the `<Rentals::Filter>` Provider Component
+## Ajouter le _Provider Component_ `<Rentals::Filter>`
 
 Now that our search query is wired up to our `<Rentals>` component, we can get into the really fun stuff! Namely, we can make our component _filter_ results based on our search query. In order to encapsulate this functionality, we'll create another component called `<Rentals::Filter>`.
 

guides/tutorial/part-2/route-params.md

@@ -6,13 +6,13 @@ Now that we are fetching real data from our "server", let's add a new feature 
 
 While adding these rental pages, you will learn about:
 
-- Routes with dynamic segments
-- Links with dynamic segments
-- Component tests with access to the router
-- Accessing parameters from dynamic segments
-- Sharing common setup code between tests
+- Routes avec segments dynamiques
+- Liens avec segments dynamiques
+- Tests de composants avec accès au routeur
+- Accéder aux paramètres des segments dynamiques
+- Partager des configurations communes entre les tests
 
-## Routes with Dynamic Segments
+## Routes avec segments dynamiques
 
 It would be great for our individual rental pages to be available through predictable URLs like `/rentals/grand-old-mansion`. Also, since these pages are dedicated to individual rentals, we can show more detailed information about each property on this page. It would also be nice to be able to have a way to bookmark a rental property, and share direct links to each individual rental listing so that our users can come back to these pages later on, after they are done browsing.
 
@@ -36,7 +36,7 @@ Router.map(function () {
 
 Notice that we are doing something a little different here. Instead of using the default path (`/rental`), we're specifying a custom path. Not only are we using a custom path, but we're also passing in a `:rental_id`, which is what we call a _[dynamic segment](../../../routing/defining-your-routes/#toc_dynamic-segments)_. When these routes are evaluated, the `rental_id` will be substituted with the `id` of the individual rental property that we are trying to navigate to.
 
-## Links with Dynamic Segments
+## Liens avec segments dynamiques
 
 Now that we have this route in place, we can update our `<Rental>` component to actually _link_ to each of our detailed rental properties!
 
@@ -178,7 +178,7 @@ If we run the tests in the browser, everything should just pass!
 
 <img src="/images/tutorial/part-2/route-params/[email protected]" alt="Tests are passing" width="1024" height="768">
 
-## Accessing Parameters from Dynamic Segments
+## Accéder aux paramètres des segments dynamiques
 
 Super&nbsp;! We're making such great progress.
 

guides/tutorial/part-2/service-injection.md

@@ -8,10 +8,10 @@ As promised, we will now work on implementing the share button!
 
 While adding the share button, you will learn about:
 
-- Splattributes and the `class` attribute
-- The router service
-- Ember services vs. global variables
-- Mocking services in tests
+- _Splattributes_ et l'attribut `class`
+- Le service routeur
+- Services Ember versus variables globales
+- _Mocker_ des services dans les tests
 
 ## Scoping the Feature
 
@@ -352,13 +352,13 @@ export default class ShareButtonComponent extends Component {
 }
 ```
 
-Here, we added the `@service router;` declaration to our component class. This injects the router service into the component, making it available to us as `this.router`. The router service has a `currentURL` property, providing the current "logical" URL as seen by Ember's router. Similar to the test helper with the same name, this is a relative URL, so we would have to join it with `window.location.origin` to get an absolute URL that we can share.
+Here, we added the `@service router;` declaration to our component class. This injects the router service into the component, making it available to us as `this.router`. Le service routeur has a `currentURL` property, providing the current "logical" URL as seen by Ember's router. Similar to the test helper with the same name, this is a relative URL, so we would have to join it with `window.location.origin` to get an absolute URL that we can share.
 
 With this change, everything is now working the way we intended.
 
 <img src="/images/tutorial/part-2/service-injection/[email protected]" alt="The previously failing test is now green" width="1024" height="960">
 
-## Ember Services vs. Global Variables
+## Services Ember versus variables globales
 
 In Ember, services serve a similar role to global variables, in that they can be easily accessed by any part of your app. For example, we can inject any available service into components, as opposed to having them passed in as an argument. This allows deeply nested components to "skip through" the layers and access things that are logically global to the entire app, such as routing, authentication, user sessions, user preferences, etc. Without services, every component would have to pass through a lot of the same arguments into every component it invokes.