Update to-go-further resources to newer or working links

Author: Ocunidee

docs/src/en/to-go-further.md

@@ -1,15 +1,15 @@
 # To go further
 
-## Lazy loading [doc](https://angular.dev/guide/routing/common-router-tasks#lazy-loading)
+## Lazy loading [doc](https://angular.dev/guide/routing/define-routes#lazily-loaded-components)
 To implement lazy loading for standalone components, routes can be defined using dynamic imports within the Angular Router. By specifying a route that points to a standalone component, the application will only load that component's code when the user navigates to the corresponding route. This approach minimizes the initial bundle size, leading to faster load times, as resources are fetched only as needed. This pattern supports better organization of code and facilitates the loading of dependencies on-demand, improving the overall efficiency of larger applications.
 
-## Form arrays [doc](https://angular.dev/api/forms/FormArray)
+## Form arrays [blog article](https://blog.angular-university.io/angular-form-array/)
 We've previously talked about `FormGroup` and `FormControl`. Both those classes inherit from `AbstractControl`. A third class inherits from it: `FormArray`. It is the third building block of reactive forms. The purpose of `FormArray` is to track the value and validity of an array of `AbstractControl`s. It is particularly useful when the number of controls is not known at build time, for instance, they are based on data returned by the backend or the user has the possibility to add them dynamically. Take a form that enables you to declare any number of backup email addresses for your account. You cannot link the form controls via their names to the inputs in the template at build time.
 
 ## Error handling [blog article](https://www.tektutorialshub.com/angular/error-handling-in-angular-applications/)
 Proper error handling is an important aspect of a well-designed application. Angular provides two building blocks to deal with errors: interceptors to deal with errors received from the backend and a `GlobalErrorHandler` to deal with client side errors. The article details a strategy to deal with both types of errors.
 
-## Resolvers [blog article](https://javascript.plainenglish.io/angular-resolver-for-prefetching-data-angular-guards-resolve-40fda257d666)
+## Resolvers [doc](https://angular.dev/guide/routing/data-resolvers)
 There are mainly two ways of dealing with a page that is heavily reliant on data received from the backend. Either load data after the page is loaded which will require a loading design and an error design for the page, in case the data is never received. Or load data before routing to the page. This alternative has the benefits of simplifying the user interface and the code. It is quite easy to implement with the Angular Router: a resolver needs to be passed to the `resolve` attribute of the route. The article explains the implementation in details.
 
 ## Translation

docs/src/fr/to-go-further.md

@@ -1,16 +1,16 @@
 # Pour aller plus loin
 
-## Lazy loading [doc](https://angular.dev/guide/routing/common-router-tasks#lazy-loading)
+## Lazy loading [Documentation](https://angular.dev/guide/routing/define-routes#lazily-loaded-components)
 Pour mettre en œuvre le lazy loading des standalone components, les routes peuvent être définies en utilisant des dynamic imports au sein du Angular Router. En spécifiant une route pointant vers un standalone component, l'application ne chargera le code de ce composant que lorsque l'utilisateur navigue vers la route correspondante. Cette approche minimise la taille du bundle initial, entraînant des temps de chargement plus rapides, car les ressources sont récupérées uniquement au besoin. Ce modèle favorise une meilleure organisation du code et facilite le chargement des dépendances à la demande, améliorant ainsi l'efficacité globale des applications plus importantes.
 
-## Les form arrays [doc](https://angular.dev/api/forms/FormArray)
+## Les form arrays [Article de blog](https://blog.angular-university.io/angular-form-array/)
 Nous avons déjà parlé de `FormGroup` et `FormControl`. Ces deux classes héritent d'`AbstractControl`. Une troisième classe en hérite : `FormArray`. C'est le troisième élément constitutif des reactive forms. Le but de `FormArray` est de suivre la valeur et la validité d'un tableau d'`AbstractControl`s. C'est particulièrement utile lorsque le nombre de controls n'est pas connu au moment de la construction, par exemple, ils sont basés sur des données renvoyées par le backend ou, l'utilisateur a la possibilité de les ajouter dynamiquement. Prenez par exemple un formulaire qui vous permet de déclarer n'importe quel nombre d'adresses e-mail de backup pour votre compte, vous ne pouvez pas lier les form controls via leur nom aux inputs dans le template au moment du build de l'application.
 
 ## Gestion des erreurs [Article de blog](https://www.tektutorialshub.com/angular/error-handling-in-angular-applications/)
 Une bonne gestion des erreurs est un aspect important d'une application bien conçue. Angular fournit deux blocs de construction pour traiter les erreurs : des intercepteurs pour traiter les erreurs reçues du backend et un `GlobalErrorHandler` pour traiter les erreurs côté client. L'article détaille une stratégie pour traiter les deux types d'erreurs.
 
-## Les resolvers [Article de blog](https://javascript.plainenglish.io/angular-resolver-for-prefetching-data-angular-guards-resolve-40fda257d666)
-Il existe principalement deux manières de traiter une page fortement dépendante des données reçues du backend. Soit charger les données après le chargement de la page, ce qui nécessitera que la page ait un design pour l'état de chargement et un pour l'état d'erreur, au cas où les données ne seraient jamais reçues. Ou charger les données avant de naviguer vers la page. Cette alternative a l'avantage de simplifier l'interface utilisateur et le code. C'est assez facile à implémenter avec le routeur Angular : un resolver doit être passé à l'attribut `resolve` de la route. L'article explique la mise en œuvre en détail.
+## Les resolvers [Documentation](https://angular.dev/guide/routing/data-resolvers)
+Il existe principalement deux manières de traiter une page fortement dépendante des données reçues du backend, soit charger les données après le chargement de la page, ce qui nécessitera que la page ait un design pour l'état de chargement et un pour l'état d'erreur, au cas où les données ne seraient jamais reçues, ou charger les données avant de naviguer vers la page. Cette alternative a l'avantage de simplifier l'interface utilisateur et le code. C'est assez facile à implémenter avec le routeur Angular : un resolver doit être passé à l'attribut `resolve` de la route. L'article explique la mise en œuvre en détail.
 
 ## Traduction
 Il est assez fréquent que les applications soient soit affichées dans la langue du navigateur, soit laissent le choix de la langue à l'utilisateur via un sélecteur (ou les deux). Angular fournit un moyen de gérer les traductions avec sa librairie d'internationalisation : `@angular/localize`. Voici la [documentation complète](https://angular.dev/guide/i18n) sur la façon de localiser une application à l'aide de la méthode officielle.