diff --git a/adev-es/src/content/best-practices/a11y.en.md b/adev-es/src/content/best-practices/a11y.en.md
new file mode 100644
index 0000000..7df1b3b
--- /dev/null
+++ b/adev-es/src/content/best-practices/a11y.en.md
@@ -0,0 +1,173 @@
+# Accessibility in Angular
+
+The web is used by a wide variety of people, including those who have visual or motor impairments.
+A variety of assistive technologies are available that make it much easier for these groups to interact with web-based software applications.
+Also, designing an application to be more accessible generally improves the user experience for all users.
+
+For an in-depth introduction to issues and techniques for designing accessible applications, see Google's web.dev [Learn Accessibility](https://web.dev/learn/accessibility/) course.
+
+This page discusses best practices for designing Angular applications that work well for all users, including those who rely on assistive technologies.
+
+## Accessibility attributes
+
+<!-- TODO: add link once attribute binding guide is implemented -->
+Building accessible web experience often involves setting [Accessible Rich Internet Applications \(ARIA\) attributes](https://web.dev/learn/accessibility/aria-html/) to provide semantic meaning where it might otherwise be missing.
+Use attribute binding template syntax to control the values of accessibility-related attributes.
+
+When binding to ARIA attributes in Angular, you must use the `attr.` prefix. The ARIA specification depends specifically on HTML attributes rather than properties of DOM elements.
+
+<docs-code language="html">
+<!-- Use attr. when binding to an ARIA attribute -->
+<button [attr.aria-label]="myActionLabel">…</button>
+</docs-code>
+
+NOTE: This syntax is only necessary for attribute *bindings*.
+Static ARIA attributes require no extra syntax.
+
+<docs-code language="html">
+<!-- Static ARIA attributes require no extra syntax -->
+<button aria-label="Save document">…</button>
+</docs-code>
+
+HELPFUL: By convention, HTML attributes use lowercase names \(`tabindex`\), while properties use camelCase names \(`tabIndex`\).
+
+<!-- TODO: add link once attribute binding guide implemented -->
+See the [Binding syntax guide](guide/templates) for more background on the difference between attributes and properties.
+
+## Angular UI components
+
+The [Angular Material](https://material.angular.dev) library, which is maintained by the Angular team, is a suite of reusable UI components that aims to be fully accessible.
+The [Component Development Kit (CDK)](https://material.angular.dev/cdk/categories) includes the `a11y` package that provides tools to support various areas of accessibility.
+For example:
+
+* `LiveAnnouncer` is used to announce messages for screen-reader users using an `aria-live` region.
+    See the W3C documentation for more information on [aria-live regions](https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-live).
+
+* The `cdkTrapFocus` directive traps Tab-key focus within an element.
+    Use it to create accessible experience for components such as modal dialogs, where focus must be constrained.
+
+For full details of these and other tools, see the [Angular CDK accessibility overview](https://material.angular.dev/cdk/a11y/overview).
+
+### Augmenting native elements
+
+Native HTML elements capture several standard interaction patterns that are important to accessibility.
+When authoring Angular components, you should re-use these native elements directly when possible, rather than re-implementing well-supported behaviors.
+
+For example, instead of creating a custom element for a new variety of button, create a component that uses an attribute selector with a native `<button>` element.
+This most commonly applies to `<button>` and `<a>`, but can be used with many other types of element.
+
+You can see examples of this pattern in Angular Material:
+[`MatButton`](https://github.com/angular/components/blob/main/src/material/button/button.ts#L33C3-L36C5), [`MatTabNav`](https://github.com/angular/components/blob/main/src/material/tabs/tab-nav-bar/tab-nav-bar.ts#L62), and [`MatTable`](https://github.com/angular/components/blob/main/src/material/table/table.ts#L40).
+
+### Using containers for native elements
+
+Sometimes using the appropriate native element requires a container element.
+For example, the native `<input>` element cannot have children, so any custom text entry components need to wrap an `<input>` with extra elements.
+By just including `<input>` in your custom component's template, it's impossible for your component's users  to set arbitrary properties and attributes to the `<input>` element.
+Instead, create a container component that uses content projection to include the native control in the component's API.
+
+You can see [`MatFormField`](https://material.angular.dev/components/form-field/overview) as an example of this pattern.
+
+## Case study: Building a custom progress bar
+
+The following example shows how to make a progress bar accessible by using host binding to control accessibility-related attributes.
+
+* The component defines an accessibility-enabled element with both the standard HTML attribute `role`, and ARIA attributes.
+    The ARIA attribute `aria-valuenow` is bound to the user's input.
+* In the template, the `aria-label` attribute ensures that the control is accessible to screen readers.
+
+<docs-code-multifile>
+  <docs-code
+    path="adev/src/content/examples/accessibility/src/app/progress-bar.component.ts"
+    language="ts"
+    linenums
+    highlight="[12, 20]"/>
+  <docs-code
+    path="adev/src/content/examples/accessibility/src/app/app.component.html"
+    language="html"
+    linenums
+    highlight="[8, 9]"/>
+</docs-code-multifile>
+
+## Routing
+
+### Focus management after navigation
+
+Tracking and controlling [focus](https://web.dev/learn/accessibility/focus/) in a UI is an important consideration in designing for accessibility.
+When using Angular routing, you should decide where page focus goes upon navigation.
+
+To avoid relying solely on visual cues, you need to make sure your routing code updates focus after page navigation.
+Use the `NavigationEnd` event from the `Router` service to know when to update focus.
+
+The following example shows how to find and focus the main content header in the DOM after navigation.
+
+<docs-code language="typescript">
+
+router.events.pipe(filter(e => e instanceof NavigationEnd)).subscribe(() => {
+  const mainHeader = document.querySelector('#main-content-header')
+  if (mainHeader) {
+    mainHeader.focus();
+  }
+});
+
+</docs-code>
+
+In a real application, the element that receives focus depends on your specific application structure and layout.
+The focused element should put users in a position to immediately move into the main content that has just been routed into view.
+You should avoid situations where focus returns to the `body` element after a route change.
+
+### Active links identification
+
+CSS classes applied to active `RouterLink` elements, such as `RouterLinkActive`, provide a visual cue to identify the active link.
+Unfortunately, a visual cue doesn't help blind or visually impaired users.
+Applying the `aria-current` attribute to the element can help identify the active link.
+For more information, see [Mozilla Developer Network \(MDN\) aria-current](https://developer.mozilla.org/docs/Web/Accessibility/ARIA/Attributes/aria-current)).
+
+The `RouterLinkActive` directive provides the `ariaCurrentWhenActive` input which sets the `aria-current` to a specified value when the link becomes active.
+
+The following example shows how to apply the `active-page` class to active links as well as setting their `aria-current` attribute to `"page"` when they are active:
+
+```angular-html
+<nav>
+  <a routerLink="home"
+      routerLinkActive="active-page"
+      ariaCurrentWhenActive="page">
+    Home
+  </a>
+  <a routerLink="about"
+      routerLinkActive="active-page"
+      ariaCurrentWhenActive="page">
+    About
+  </a>
+  <a routerLink="shop"
+      routerLinkActive="active-page"
+      ariaCurrentWhenActive="page">
+    Shop
+  </a>
+</nav>
+```
+
+<!-- vale Angular.Angular_Spelling = NO -->
+
+## More information
+
+* [Accessibility - Google Web Fundamentals](https://developers.google.com/web/fundamentals/accessibility)
+* [ARIA specification and authoring practices](https://www.w3.org/TR/wai-aria)
+* [Material Design - Accessibility](https://material.io/design/usability/accessibility.html)
+* [Smashing Magazine](https://www.smashingmagazine.com/search/?q=accessibility)
+* [Inclusive Components](https://inclusive-components.design)
+* [Accessibility Resources and Code Examples](https://dequeuniversity.com/resources)
+* [W3C - Web Accessibility Initiative](https://www.w3.org/WAI/people-use-web)
+* [Rob Dodson A11ycasts](https://www.youtube.com/watch?v=HtTyRajRuyY)
+* [Angular ESLint](https://github.com/angular-eslint/angular-eslint#functionality) provides linting rules that can help you make sure your code meets accessibility standards.
+
+<!-- vale Angular.Angular_Spelling = YES -->
+
+Books
+
+<!-- vale Angular.Google_Quotes = NO -->
+
+* "A Web for Everyone: Designing Accessible User Experiences," Sarah Horton and Whitney Quesenbery
+* "Inclusive Design Patterns," Heydon Pickering
+
+<!-- vale Angular.Google_Quotes = YES -->
diff --git a/adev-es/src/content/best-practices/a11y.md b/adev-es/src/content/best-practices/a11y.md
index 7df1b3b..444eb7d 100644
--- a/adev-es/src/content/best-practices/a11y.md
+++ b/adev-es/src/content/best-practices/a11y.md
@@ -1,80 +1,80 @@
-# Accessibility in Angular
+# Accesibilidad en Angular
 
-The web is used by a wide variety of people, including those who have visual or motor impairments.
-A variety of assistive technologies are available that make it much easier for these groups to interact with web-based software applications.
-Also, designing an application to be more accessible generally improves the user experience for all users.
+La web es utilizada por una amplia variedad de personas, incluidas aquellas que tienen deficiencias visuales o motoras.
+Existen diversas tecnologías de asistencia disponibles que facilitan mucho la interacción de estos grupos con aplicaciones de software basadas en la web.
+Además, diseñar una aplicación para que sea más accesible generalmente mejora la experiencia del usuario para todos los usuarios.
 
-For an in-depth introduction to issues and techniques for designing accessible applications, see Google's web.dev [Learn Accessibility](https://web.dev/learn/accessibility/) course.
+Para una introducción en profundidad sobre los problemas y técnicas para diseñar aplicaciones accesibles, consulta el curso [Learn Accessibility](https://web.dev/learn/accessibility/) de web.dev de Google.
 
-This page discusses best practices for designing Angular applications that work well for all users, including those who rely on assistive technologies.
+Esta página aborda las mejores prácticas para diseñar aplicaciones Angular que funcionen bien para todos los usuarios, incluidos aquellos que dependen de tecnologías de asistencia.
 
-## Accessibility attributes
+## Atributos de accesibilidad
 
 <!-- TODO: add link once attribute binding guide is implemented -->
-Building accessible web experience often involves setting [Accessible Rich Internet Applications \(ARIA\) attributes](https://web.dev/learn/accessibility/aria-html/) to provide semantic meaning where it might otherwise be missing.
-Use attribute binding template syntax to control the values of accessibility-related attributes.
+Construir experiencias web accesibles a menudo implica establecer [atributos de Aplicaciones de Internet Enriquecidas Accesibles (ARIA)](https://web.dev/learn/accessibility/aria-html/) para proporcionar significado semántico donde de otro modo podría faltar.
+Usa la sintaxis de plantilla de enlace de atributo para controlar los valores de los atributos relacionados con la accesibilidad.
 
-When binding to ARIA attributes in Angular, you must use the `attr.` prefix. The ARIA specification depends specifically on HTML attributes rather than properties of DOM elements.
+Al enlazar a atributos ARIA en Angular, debes usar el prefijo `attr.`. La especificación ARIA depende específicamente de atributos HTML en lugar de propiedades de elementos DOM.
 
 <docs-code language="html">
-<!-- Use attr. when binding to an ARIA attribute -->
+<!-- Usa attr. al enlazar a un atributo ARIA -->
 <button [attr.aria-label]="myActionLabel">…</button>
 </docs-code>
 
-NOTE: This syntax is only necessary for attribute *bindings*.
-Static ARIA attributes require no extra syntax.
+NOTA: Esta sintaxis solo es necesaria para *enlaces* de atributo.
+Los atributos ARIA estáticos no requieren sintaxis adicional.
 
 <docs-code language="html">
-<!-- Static ARIA attributes require no extra syntax -->
+<!-- Los atributos ARIA estáticos no requieren sintaxis adicional -->
 <button aria-label="Save document">…</button>
 </docs-code>
 
-HELPFUL: By convention, HTML attributes use lowercase names \(`tabindex`\), while properties use camelCase names \(`tabIndex`\).
+ÚTIL: Por convención, los atributos HTML usan nombres en minúsculas (`tabindex`), mientras que las propiedades usan nombres en camelCase (`tabIndex`).
 
 <!-- TODO: add link once attribute binding guide implemented -->
-See the [Binding syntax guide](guide/templates) for more background on the difference between attributes and properties.
+Consulta la [guía de sintaxis de enlace](guide/templates) para más información sobre la diferencia entre atributos y propiedades.
 
-## Angular UI components
+## Componentes UI de Angular
 
-The [Angular Material](https://material.angular.dev) library, which is maintained by the Angular team, is a suite of reusable UI components that aims to be fully accessible.
-The [Component Development Kit (CDK)](https://material.angular.dev/cdk/categories) includes the `a11y` package that provides tools to support various areas of accessibility.
-For example:
+La biblioteca [Angular Material](https://material.angular.dev), que es mantenida por el equipo de Angular, es un conjunto de componentes UI reutilizables que busca ser completamente accesible.
+El [Component Development Kit (CDK)](https://material.angular.dev/cdk/categories) incluye el paquete `a11y` que proporciona herramientas para soportar diversas áreas de accesibilidad.
+Por ejemplo:
 
-* `LiveAnnouncer` is used to announce messages for screen-reader users using an `aria-live` region.
-    See the W3C documentation for more information on [aria-live regions](https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-live).
+* `LiveAnnouncer` se usa para anunciar mensajes para usuarios de lectores de pantalla usando una región `aria-live`.
+    Consulta la documentación de W3C para más información sobre [regiones aria-live](https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-live).
 
-* The `cdkTrapFocus` directive traps Tab-key focus within an element.
-    Use it to create accessible experience for components such as modal dialogs, where focus must be constrained.
+* La directiva `cdkTrapFocus` atrapa el foco de la tecla Tab dentro de un elemento.
+    Úsala para crear experiencias accesibles para componentes como diálogos modales, donde el foco debe estar restringido.
 
-For full details of these and other tools, see the [Angular CDK accessibility overview](https://material.angular.dev/cdk/a11y/overview).
+Para detalles completos de estas y otras herramientas, consulta la [visión general de accesibilidad de Angular CDK](https://material.angular.dev/cdk/a11y/overview).
 
-### Augmenting native elements
+### Aumentando elementos nativos
 
-Native HTML elements capture several standard interaction patterns that are important to accessibility.
-When authoring Angular components, you should re-use these native elements directly when possible, rather than re-implementing well-supported behaviors.
+Los elementos HTML nativos capturan varios patrones de interacción estándar que son importantes para la accesibilidad.
+Al crear componentes de Angular, debes reutilizar estos elementos nativos directamente cuando sea posible, en lugar de reimplementar comportamientos bien soportados.
 
-For example, instead of creating a custom element for a new variety of button, create a component that uses an attribute selector with a native `<button>` element.
-This most commonly applies to `<button>` and `<a>`, but can be used with many other types of element.
+Por ejemplo, en lugar de crear un elemento personalizado para una nueva variedad de botón, crea un componente que use un selector de atributo con un elemento `<button>` nativo.
+Esto se aplica más comúnmente a `<button>` y `<a>`, pero puede usarse con muchos otros tipos de elementos.
 
-You can see examples of this pattern in Angular Material:
-[`MatButton`](https://github.com/angular/components/blob/main/src/material/button/button.ts#L33C3-L36C5), [`MatTabNav`](https://github.com/angular/components/blob/main/src/material/tabs/tab-nav-bar/tab-nav-bar.ts#L62), and [`MatTable`](https://github.com/angular/components/blob/main/src/material/table/table.ts#L40).
+Puedes ver ejemplos de este patrón en Angular Material:
+[`MatButton`](https://github.com/angular/components/blob/main/src/material/button/button.ts#L33C3-L36C5), [`MatTabNav`](https://github.com/angular/components/blob/main/src/material/tabs/tab-nav-bar/tab-nav-bar.ts#L62), y [`MatTable`](https://github.com/angular/components/blob/main/src/material/table/table.ts#L40).
 
-### Using containers for native elements
+### Usando contenedores para elementos nativos
 
-Sometimes using the appropriate native element requires a container element.
-For example, the native `<input>` element cannot have children, so any custom text entry components need to wrap an `<input>` with extra elements.
-By just including `<input>` in your custom component's template, it's impossible for your component's users  to set arbitrary properties and attributes to the `<input>` element.
-Instead, create a container component that uses content projection to include the native control in the component's API.
+A veces, usar el elemento nativo apropiado requiere un elemento contenedor.
+Por ejemplo, el elemento nativo `<input>` no puede tener hijos, por lo que cualquier componente personalizado de entrada de texto necesita envolver un `<input>` con elementos adicionales.
+Al simplemente incluir `<input>` en la plantilla de tu componente personalizado, es imposible para los usuarios de tu componente establecer propiedades y atributos arbitrarios al elemento `<input>`.
+En su lugar, crea un componente contenedor que use proyección de contenido para incluir el control nativo en la API del componente.
 
-You can see [`MatFormField`](https://material.angular.dev/components/form-field/overview) as an example of this pattern.
+Puedes ver [`MatFormField`](https://material.angular.dev/components/form-field/overview) como ejemplo de este patrón.
 
-## Case study: Building a custom progress bar
+## Caso de estudio: Construyendo una barra de progreso personalizada
 
-The following example shows how to make a progress bar accessible by using host binding to control accessibility-related attributes.
+El siguiente ejemplo muestra cómo hacer accesible una barra de progreso usando host binding para controlar atributos relacionados con la accesibilidad.
 
-* The component defines an accessibility-enabled element with both the standard HTML attribute `role`, and ARIA attributes.
-    The ARIA attribute `aria-valuenow` is bound to the user's input.
-* In the template, the `aria-label` attribute ensures that the control is accessible to screen readers.
+* El componente define un elemento habilitado para accesibilidad con tanto el atributo HTML estándar `role`, como atributos ARIA.
+    El atributo ARIA `aria-valuenow` está enlazado a la entrada del usuario.
+* En la plantilla, el atributo `aria-label` asegura que el control sea accesible para lectores de pantalla.
 
 <docs-code-multifile>
   <docs-code
@@ -89,17 +89,17 @@ The following example shows how to make a progress bar accessible by using host
     highlight="[8, 9]"/>
 </docs-code-multifile>
 
-## Routing
+## Enrutamiento
 
-### Focus management after navigation
+### Gestión del foco después de la navegación
 
-Tracking and controlling [focus](https://web.dev/learn/accessibility/focus/) in a UI is an important consideration in designing for accessibility.
-When using Angular routing, you should decide where page focus goes upon navigation.
+Rastrear y controlar el [foco](https://web.dev/learn/accessibility/focus/) en una UI es una consideración importante al diseñar para accesibilidad.
+Al usar el enrutamiento de Angular, debes decidir dónde va el foco de la página al navegar.
 
-To avoid relying solely on visual cues, you need to make sure your routing code updates focus after page navigation.
-Use the `NavigationEnd` event from the `Router` service to know when to update focus.
+Para evitar depender únicamente de señales visuales, necesitas asegurarte de que tu código de enrutamiento actualice el foco después de la navegación de la página.
+Usa el evento `NavigationEnd` del servicio `Router` para saber cuándo actualizar el foco.
 
-The following example shows how to find and focus the main content header in the DOM after navigation.
+El siguiente ejemplo muestra cómo encontrar y enfocar el encabezado de contenido principal en el DOM después de la navegación.
 
 <docs-code language="typescript">
 
@@ -112,20 +112,20 @@ router.events.pipe(filter(e => e instanceof NavigationEnd)).subscribe(() => {
 
 </docs-code>
 
-In a real application, the element that receives focus depends on your specific application structure and layout.
-The focused element should put users in a position to immediately move into the main content that has just been routed into view.
-You should avoid situations where focus returns to the `body` element after a route change.
+En una aplicación real, el elemento que recibe el foco depende de la estructura y diseño específicos de tu aplicación.
+El elemento enfocado debe poner a los usuarios en una posición para moverse inmediatamente al contenido principal que acaba de ser enrutado a la vista.
+Debes evitar situaciones donde el foco regresa al elemento `body` después de un cambio de ruta.
 
-### Active links identification
+### Identificación de enlaces activos
 
-CSS classes applied to active `RouterLink` elements, such as `RouterLinkActive`, provide a visual cue to identify the active link.
-Unfortunately, a visual cue doesn't help blind or visually impaired users.
-Applying the `aria-current` attribute to the element can help identify the active link.
-For more information, see [Mozilla Developer Network \(MDN\) aria-current](https://developer.mozilla.org/docs/Web/Accessibility/ARIA/Attributes/aria-current)).
+Las clases CSS aplicadas a elementos `RouterLink` activos, como `RouterLinkActive`, proporcionan una señal visual para identificar el enlace activo.
+Desafortunadamente, una señal visual no ayuda a usuarios ciegos o con deficiencia visual.
+Aplicar el atributo `aria-current` al elemento puede ayudar a identificar el enlace activo.
+Para más información, consulta [Mozilla Developer Network (MDN) aria-current](https://developer.mozilla.org/docs/Web/Accessibility/ARIA/Attributes/aria-current)).
 
-The `RouterLinkActive` directive provides the `ariaCurrentWhenActive` input which sets the `aria-current` to a specified value when the link becomes active.
+La directiva `RouterLinkActive` proporciona la entrada `ariaCurrentWhenActive` que establece el `aria-current` a un valor especificado cuando el enlace se vuelve activo.
 
-The following example shows how to apply the `active-page` class to active links as well as setting their `aria-current` attribute to `"page"` when they are active:
+El siguiente ejemplo muestra cómo aplicar la clase `active-page` a los enlaces activos así como establecer su atributo `aria-current` a `"page"` cuando están activos:
 
 ```angular-html
 <nav>
@@ -149,7 +149,7 @@ The following example shows how to apply the `active-page` class to active links
 
 <!-- vale Angular.Angular_Spelling = NO -->
 
-## More information
+## Más información
 
 * [Accessibility - Google Web Fundamentals](https://developers.google.com/web/fundamentals/accessibility)
 * [ARIA specification and authoring practices](https://www.w3.org/TR/wai-aria)
@@ -159,11 +159,11 @@ The following example shows how to apply the `active-page` class to active links
 * [Accessibility Resources and Code Examples](https://dequeuniversity.com/resources)
 * [W3C - Web Accessibility Initiative](https://www.w3.org/WAI/people-use-web)
 * [Rob Dodson A11ycasts](https://www.youtube.com/watch?v=HtTyRajRuyY)
-* [Angular ESLint](https://github.com/angular-eslint/angular-eslint#functionality) provides linting rules that can help you make sure your code meets accessibility standards.
+* [Angular ESLint](https://github.com/angular-eslint/angular-eslint#functionality) proporciona reglas de linting que pueden ayudarte a asegurarte de que tu código cumpla con los estándares de accesibilidad.
 
 <!-- vale Angular.Angular_Spelling = YES -->
 
-Books
+Libros
 
 <!-- vale Angular.Google_Quotes = NO -->
 
diff --git a/adev-es/src/content/best-practices/error-handling.en.md b/adev-es/src/content/best-practices/error-handling.en.md
new file mode 100644
index 0000000..36dbb05
--- /dev/null
+++ b/adev-es/src/content/best-practices/error-handling.en.md
@@ -0,0 +1,42 @@
+# Unhandled errors in Angular
+
+As your Angular application runs, some of your code may throw an error. If left unhandled, these errors can lead to unexpected behavior and a nonresponsive UI. This guide covers how Angular deals with errors that are not explicitly caught by your application code. For guidance on writing your own error handling logic within your application, consult best practices for error handling in JavaScript and Angular.
+
+A fundamental principle in Angular's error handling strategy is that errors should be surfaced to developers at the callsite whenever possible. This approach ensures that the code which initiated an operation has the context necessary to understand the error, handle it appropriately, and decide what the appropriate application state should be. By making errors visible at their origin, developers can implement error handling that is specific to the failed operation and has access to relevant information for recovery or providing informative feedback to the end-user. This also helps to avoid the "Overly general error" smell, where errors are reported without sufficient context to understand their cause.
+
+For example, consider a component that fetches user data from an API. The code responsible for making the API call should include error handling (e.g., using a `try...catch` block or the `catchError` operator in RxJS) to manage potential network issues or errors returned by the API. This allows the component to display a user-friendly error message or retry the request, rather than letting the error propagate unhandled.
+
+## Unhandled errors are reported to the `ErrorHandler`
+
+Angular reports unhandled errors to the application's root [ErrorHandler](api/core/ErrorHandler). When providing a custom `ErrorHandler`, provide it in your `ApplicationConfig` as part of calling `bootstrapApplication`.
+
+When building an Angular application, often you write code that is called automatically _by_ the framework. For example, Angular is responsible for calling a component's constructor and lifecycle methods when that component appears in a template. When the framework runs your code, there's nowhere you could reasonably add a `try` block to gracefully handle errors. In situations like this, Angular catches errors and sends them to the `ErrorHandler`.
+
+Angular does _not_ catch errors inside of APIs that are called directly by your code. For example, if you have a service with a method that throws an error and you call that method in your component, Angular will not automatically catch that error. You are responsible for handling it using mechanisms like `try...catch`.
+
+Angular catches _asynchronous_ errors from user promises or observables only when:
+
+* There is an explicit contract for Angular to wait for and use the result of the asynchronous operation, and
+* When errors are not presented in the return value or state.
+
+For example, `AsyncPipe` and `PendingTasks.run` forward errors to the `ErrorHandler`, whereas `resource` presents the error in the `status` and `error` properties.
+
+Errors that Angular reports to the `ErrorHandler` are _unexpected_ errors. These errors may be unrecoverable or an indication that the state of the application is corrupted. Applications should provide error handling using `try` blocks or appropriate error handling operators (like `catchError` in RxJS) where the error occurs whenever possible rather than relying on the `ErrorHandler`, which is most frequently and appropriately used only as a mechanism to report potentially fatal errors to the error tracking and logging infrastructure.
+
+### `TestBed` rethrows errors by default
+
+In many cases, `ErrorHandler` may only log errors and otherwise allow the application to continue running. In tests, however, you almost always want to surface these errors. Angular's `TestBed` rethrows unexpected errors to ensure that errors caught by the framework cannot be unintentionally missed or ignored. In rare circumstances, a test may specifically attempt to ensure errors do not cause the application to be unresponsive or crash. In these situations, you can [configure `TestBed` to _not_ rethrow application errors](api/core/testing/TestModuleMetadata#rethrowApplicationErrors) with `TestBed.configureTestingModule({rethrowApplicationErrors: false})`.
+
+## Global error listeners
+
+Errors that are caught neither by the application code nor by the framework's application instance may reach the global scope. Errors reaching the global scope can have unintended consequences if not accounted for. In non-browser environments, they may cause the process to crash. In the browser, these errors may go unreported and site visitors may see the errors in the browser console. Angular provides global listeners for both environments to account for these issues.
+
+### Client-side rendering
+
+Adding [`provideBrowserGlobalErrorListeners()`](/api/core/provideBrowserGlobalErrorListeners) to the [ApplicationConfig](guide/di/dependency-injection#at-the-application-root-level-using-applicationconfig) adds the `'error'` and `'unhandledrejection'` listeners to the browser window and forwards those errors to `ErrorHandler`. The Angular CLI generates new applications with this provider by default. The Angular team recommends handling these global errors for most applications, either with the framework's built-in listeners or with your own custom listeners. If you provide custom listeners, you can remove `provideBrowserGlobalErrorListeners`.
+
+### Server-side and hybrid rendering
+
+When using [Angular with SSR](guide/ssr), Angular automatically adds the `'unhandledRejection'` and `'uncaughtException'` listeners to the server process. These handlers prevent the server from crashing and instead log captured errors to the console.
+
+IMPORTANT: If the application is using Zone.js, only the `'unhandledRejection'` handler is added. When Zone.js is present, errors inside the Application's Zone are already forwarded to the application `ErrorHandler` and do not reach the server process.
diff --git a/adev-es/src/content/best-practices/error-handling.md b/adev-es/src/content/best-practices/error-handling.md
index 36dbb05..528088f 100644
--- a/adev-es/src/content/best-practices/error-handling.md
+++ b/adev-es/src/content/best-practices/error-handling.md
@@ -1,42 +1,42 @@
-# Unhandled errors in Angular
+# Errores no manejados en Angular
 
-As your Angular application runs, some of your code may throw an error. If left unhandled, these errors can lead to unexpected behavior and a nonresponsive UI. This guide covers how Angular deals with errors that are not explicitly caught by your application code. For guidance on writing your own error handling logic within your application, consult best practices for error handling in JavaScript and Angular.
+A medida que tu aplicación Angular se ejecuta, parte de tu código puede lanzar un error. Si no se maneja, estos errores pueden llevar a un comportamiento inesperado y una UI que no responde. Esta guía cubre cómo Angular maneja errores que no son atrapados explícitamente por el código de tu aplicación. Para orientación sobre escribir tu propia lógica de manejo de errores dentro de tu aplicación, consulta las mejores prácticas para el manejo de errores en JavaScript y Angular.
 
-A fundamental principle in Angular's error handling strategy is that errors should be surfaced to developers at the callsite whenever possible. This approach ensures that the code which initiated an operation has the context necessary to understand the error, handle it appropriately, and decide what the appropriate application state should be. By making errors visible at their origin, developers can implement error handling that is specific to the failed operation and has access to relevant information for recovery or providing informative feedback to the end-user. This also helps to avoid the "Overly general error" smell, where errors are reported without sufficient context to understand their cause.
+Un principio fundamental en la estrategia de manejo de errores de Angular es que los errores deben ser expuestos a los desarrolladores en el sitio de llamada siempre que sea posible. Este enfoque asegura que el código que inició una operación tenga el contexto necesario para entender el error, manejarlo apropiadamente, y decidir cuál debe ser el estado apropiado de la aplicación. Al hacer visibles los errores en su origen, los desarrolladores pueden implementar manejo de errores que sea específico para la operación fallida y tenga acceso a información relevante para la recuperación o para proporcionar retroalimentación informativa al usuario final. Esto también ayuda a evitar el smell de "Error demasiado general", donde los errores se reportan sin suficiente contexto para entender su causa.
 
-For example, consider a component that fetches user data from an API. The code responsible for making the API call should include error handling (e.g., using a `try...catch` block or the `catchError` operator in RxJS) to manage potential network issues or errors returned by the API. This allows the component to display a user-friendly error message or retry the request, rather than letting the error propagate unhandled.
+Por ejemplo, considera un componente que obtiene datos de usuario desde una API. El código responsable de hacer la llamada a la API debe incluir manejo de errores (por ejemplo, usando un bloque `try...catch` o el operador `catchError` en RxJS) para gestionar potenciales problemas de red o errores devueltos por la API. Esto permite al componente mostrar un mensaje de error amigable para el usuario o reintentar la petición, en lugar de dejar que el error se propague sin manejar.
 
-## Unhandled errors are reported to the `ErrorHandler`
+## Los errores no manejados son reportados al `ErrorHandler`
 
-Angular reports unhandled errors to the application's root [ErrorHandler](api/core/ErrorHandler). When providing a custom `ErrorHandler`, provide it in your `ApplicationConfig` as part of calling `bootstrapApplication`.
+Angular reporta errores no manejados al [ErrorHandler](api/core/ErrorHandler) raíz de la aplicación. Al proporcionar un `ErrorHandler` personalizado, proporciónalo en tu `ApplicationConfig` como parte de la llamada a `bootstrapApplication`.
 
-When building an Angular application, often you write code that is called automatically _by_ the framework. For example, Angular is responsible for calling a component's constructor and lifecycle methods when that component appears in a template. When the framework runs your code, there's nowhere you could reasonably add a `try` block to gracefully handle errors. In situations like this, Angular catches errors and sends them to the `ErrorHandler`.
+Al construir una aplicación Angular, a menudo escribes código que es llamado automáticamente _por_ el framework. Por ejemplo, Angular es responsable de llamar al constructor de un componente y a los métodos de ciclo de vida cuando ese componente aparece en una plantilla. Cuando el framework ejecuta tu código, no hay lugar donde puedas razonablemente agregar un bloque `try` para manejar errores con gracia. En situaciones como esta, Angular captura errores y los envía al `ErrorHandler`.
 
-Angular does _not_ catch errors inside of APIs that are called directly by your code. For example, if you have a service with a method that throws an error and you call that method in your component, Angular will not automatically catch that error. You are responsible for handling it using mechanisms like `try...catch`.
+Angular _no_ captura errores dentro de APIs que son llamadas directamente por tu código. Por ejemplo, si tienes un servicio con un método que lanza un error y llamas a ese método en tu componente, Angular no capturará automáticamente ese error. Eres responsable de manejarlo usando mecanismos como `try...catch`.
 
-Angular catches _asynchronous_ errors from user promises or observables only when:
+Angular captura errores _asíncronos_ de promesas de usuario u observables solo cuando:
 
-* There is an explicit contract for Angular to wait for and use the result of the asynchronous operation, and
-* When errors are not presented in the return value or state.
+* Hay un contrato explícito para que Angular espere y use el resultado de la operación asíncrona, y
+* Cuando los errores no se presentan en el valor de retorno o estado.
 
-For example, `AsyncPipe` and `PendingTasks.run` forward errors to the `ErrorHandler`, whereas `resource` presents the error in the `status` and `error` properties.
+Por ejemplo, `AsyncPipe` y `PendingTasks.run` reenvían errores al `ErrorHandler`, mientras que `resource` presenta el error en las propiedades `status` y `error`.
 
-Errors that Angular reports to the `ErrorHandler` are _unexpected_ errors. These errors may be unrecoverable or an indication that the state of the application is corrupted. Applications should provide error handling using `try` blocks or appropriate error handling operators (like `catchError` in RxJS) where the error occurs whenever possible rather than relying on the `ErrorHandler`, which is most frequently and appropriately used only as a mechanism to report potentially fatal errors to the error tracking and logging infrastructure.
+Los errores que Angular reporta al `ErrorHandler` son errores _inesperados_. Estos errores pueden ser irrecuperables o una indicación de que el estado de la aplicación está corrupto. Las aplicaciones deben proporcionar manejo de errores usando bloques `try` u operadores apropiados de manejo de errores (como `catchError` en RxJS) donde ocurre el error siempre que sea posible en lugar de depender del `ErrorHandler`, que se usa con más frecuencia y apropiadamente solo como un mecanismo para reportar errores potencialmente fatales a la infraestructura de seguimiento de errores y logging.
 
-### `TestBed` rethrows errors by default
+### `TestBed` relanza errores por defecto
 
-In many cases, `ErrorHandler` may only log errors and otherwise allow the application to continue running. In tests, however, you almost always want to surface these errors. Angular's `TestBed` rethrows unexpected errors to ensure that errors caught by the framework cannot be unintentionally missed or ignored. In rare circumstances, a test may specifically attempt to ensure errors do not cause the application to be unresponsive or crash. In these situations, you can [configure `TestBed` to _not_ rethrow application errors](api/core/testing/TestModuleMetadata#rethrowApplicationErrors) with `TestBed.configureTestingModule({rethrowApplicationErrors: false})`.
+En muchos casos, `ErrorHandler` puede solo registrar errores y de otra manera permitir que la aplicación continúe ejecutándose. En pruebas, sin embargo, casi siempre quieres exponer estos errores. El `TestBed` de Angular relanza errores inesperados para asegurar que los errores capturados por el framework no puedan ser perdidos o ignorados sin intención. En circunstancias raras, una prueba puede intentar específicamente asegurar que los errores no causen que la aplicación no responda o se bloquee. En estas situaciones, puedes [configurar `TestBed` para _no_ relanzar errores de aplicación](api/core/testing/TestModuleMetadata#rethrowApplicationErrors) con `TestBed.configureTestingModule({rethrowApplicationErrors: false})`.
 
-## Global error listeners
+## Escuchadores globales de errores
 
-Errors that are caught neither by the application code nor by the framework's application instance may reach the global scope. Errors reaching the global scope can have unintended consequences if not accounted for. In non-browser environments, they may cause the process to crash. In the browser, these errors may go unreported and site visitors may see the errors in the browser console. Angular provides global listeners for both environments to account for these issues.
+Los errores que no son capturados ni por el código de la aplicación ni por la instancia de aplicación del framework pueden alcanzar el alcance global. Los errores que alcanzan el alcance global pueden tener consecuencias no deseadas si no se tienen en cuenta. En entornos que no son navegadores, pueden causar que el proceso se bloquee. En el navegador, estos errores pueden no ser reportados y los visitantes del sitio pueden ver los errores en la consola del navegador. Angular proporciona escuchadores globales para ambos entornos para tener en cuenta estos problemas.
 
-### Client-side rendering
+### Renderización del lado del cliente
 
-Adding [`provideBrowserGlobalErrorListeners()`](/api/core/provideBrowserGlobalErrorListeners) to the [ApplicationConfig](guide/di/dependency-injection#at-the-application-root-level-using-applicationconfig) adds the `'error'` and `'unhandledrejection'` listeners to the browser window and forwards those errors to `ErrorHandler`. The Angular CLI generates new applications with this provider by default. The Angular team recommends handling these global errors for most applications, either with the framework's built-in listeners or with your own custom listeners. If you provide custom listeners, you can remove `provideBrowserGlobalErrorListeners`.
+Agregar [`provideBrowserGlobalErrorListeners()`](/api/core/provideBrowserGlobalErrorListeners) al [ApplicationConfig](guide/di/dependency-injection#at-the-application-root-level-using-applicationconfig) agrega los escuchadores `'error'` y `'unhandledrejection'` a la ventana del navegador y reenvía esos errores al `ErrorHandler`. El CLI de Angular genera nuevas aplicaciones con este proveedor por defecto. El equipo de Angular recomienda manejar estos errores globales para la mayoría de las aplicaciones, ya sea con los escuchadores integrados del framework o con tus propios escuchadores personalizados. Si proporcionas escuchadores personalizados, puedes eliminar `provideBrowserGlobalErrorListeners`.
 
-### Server-side and hybrid rendering
+### Renderización del lado del servidor e híbrida
 
-When using [Angular with SSR](guide/ssr), Angular automatically adds the `'unhandledRejection'` and `'uncaughtException'` listeners to the server process. These handlers prevent the server from crashing and instead log captured errors to the console.
+Al usar [Angular con SSR](guide/ssr), Angular agrega automáticamente los escuchadores `'unhandledRejection'` y `'uncaughtException'` al proceso del servidor. Estos manejadores previenen que el servidor se bloquee y en su lugar registran los errores capturados en la consola.
 
-IMPORTANT: If the application is using Zone.js, only the `'unhandledRejection'` handler is added. When Zone.js is present, errors inside the Application's Zone are already forwarded to the application `ErrorHandler` and do not reach the server process.
+IMPORTANTE: Si la aplicación está usando Zone.js, solo se agrega el manejador `'unhandledRejection'`. Cuando Zone.js está presente, los errores dentro de la Zone de la aplicación ya son reenviados al `ErrorHandler` de la aplicación y no alcanzan el proceso del servidor.
diff --git a/adev-es/src/content/best-practices/runtime-performance/overview.en.md b/adev-es/src/content/best-practices/runtime-performance/overview.en.md
new file mode 100644
index 0000000..2023383
--- /dev/null
+++ b/adev-es/src/content/best-practices/runtime-performance/overview.en.md
@@ -0,0 +1,13 @@
+# Runtime performance optimization
+
+Fast rendering is critical for Angular and we've built the framework with a lot of optimizations in mind to help you develop performant apps. To better understand the performance of your app we offer [Angular DevTools](tools/devtools) and a [video guide](https://www.youtube.com/watch?v=FjyX_hkscII) on how to use Chrome DevTools for profiling. In this section we cover the most common performance optimization techniques.
+
+**Change detection** is the process through which Angular checks to see whether your application state has changed, and if any DOM needs to be updated. At a high level, Angular walks your components from top to bottom, looking for changes. Angular runs its change detection mechanism periodically so that changes to the data model are reflected in an application’s view. Change detection can be triggered either manually or through an asynchronous event (for example, a user interaction or an XMLHttpRequest completion).
+
+Change detection is highly optimized and performant, but it can still cause slowdowns if the application runs it too frequently.
+
+In this guide, you’ll learn how to control and optimize the change detection mechanism by skipping parts of your application and running change detection only when necessary.
+
+Watch this video if you prefer to learn more about performance optimizations in a media format:
+
+<docs-video src="https://www.youtube.com/embed/f8sA-i6gkGQ"/>
diff --git a/adev-es/src/content/best-practices/runtime-performance/overview.md b/adev-es/src/content/best-practices/runtime-performance/overview.md
index 2023383..4ba0e7d 100644
--- a/adev-es/src/content/best-practices/runtime-performance/overview.md
+++ b/adev-es/src/content/best-practices/runtime-performance/overview.md
@@ -1,13 +1,13 @@
-# Runtime performance optimization
+# Optimización del rendimiento en tiempo de ejecución
 
-Fast rendering is critical for Angular and we've built the framework with a lot of optimizations in mind to help you develop performant apps. To better understand the performance of your app we offer [Angular DevTools](tools/devtools) and a [video guide](https://www.youtube.com/watch?v=FjyX_hkscII) on how to use Chrome DevTools for profiling. In this section we cover the most common performance optimization techniques.
+La renderización rápida es crítica para Angular y hemos construido el framework con muchas optimizaciones en mente para ayudarte a desarrollar aplicaciones de alto rendimiento. Para entender mejor el rendimiento de tu aplicación, ofrecemos [Angular DevTools](tools/devtools) y una [guía en video](https://www.youtube.com/watch?v=FjyX_hkscII) sobre cómo usar Chrome DevTools para perfilado. En esta sección cubrimos las técnicas de optimización de rendimiento más comunes.
 
-**Change detection** is the process through which Angular checks to see whether your application state has changed, and if any DOM needs to be updated. At a high level, Angular walks your components from top to bottom, looking for changes. Angular runs its change detection mechanism periodically so that changes to the data model are reflected in an application’s view. Change detection can be triggered either manually or through an asynchronous event (for example, a user interaction or an XMLHttpRequest completion).
+**Change detection** es el proceso a través del cual Angular verifica si el estado de tu aplicación ha cambiado, y si algún DOM necesita ser actualizado. A alto nivel, Angular recorre tus componentes de arriba hacia abajo, buscando cambios. Angular ejecuta su mecanismo de change detection periódicamente para que los cambios en el modelo de datos se reflejen en la vista de la aplicación. El change detection puede ser disparado manual o a través de un evento asíncrono (por ejemplo, una interacción del usuario o la finalización de un XMLHttpRequest).
 
-Change detection is highly optimized and performant, but it can still cause slowdowns if the application runs it too frequently.
+El change detection está altamente optimizado y es eficiente, pero aún puede causar ralentizaciones si la aplicación lo ejecuta con demasiada frecuencia.
 
-In this guide, you’ll learn how to control and optimize the change detection mechanism by skipping parts of your application and running change detection only when necessary.
+En esta guía, aprenderás cómo controlar y optimizar el mecanismo de change detection omitiendo partes de tu aplicación y ejecutando change detection solo cuando sea necesario.
 
-Watch this video if you prefer to learn more about performance optimizations in a media format:
+Mira este video si prefieres aprender más sobre optimizaciones de rendimiento en formato multimedia:
 
 <docs-video src="https://www.youtube.com/embed/f8sA-i6gkGQ"/>
diff --git a/adev-es/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.en.md b/adev-es/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.en.md
new file mode 100644
index 0000000..c78d6c2
--- /dev/null
+++ b/adev-es/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.en.md
@@ -0,0 +1,100 @@
+# Profiling with the Chrome DevTools
+
+Angular integrates with the [Chrome DevTools extensibility API](https://developer.chrome.com/docs/devtools/performance/extension) to present framework-specific data and insights directly in the [Chrome DevTools performance panel](https://developer.chrome.com/docs/devtools/performance/overview).
+
+With the integration enabled, you can [record a performance profile](https://developer.chrome.com/docs/devtools/performance#record) containing two sets of data:
+
+- Standard performance entries based on Chrome's understanding of your code executing in a browser, and
+- Angular-specific entries contributed by the framework's runtime.
+
+Both sets of data are presented together on the same tab, but on separate tracks:
+
+<img alt="Angular custom track in Chrome DevTools profiler" src="assets/images/best-practices/runtime-performance/angular-perf-in-chrome.png">
+
+Angular-specific data are expressed in terms of framework concepts (components, change detection, lifecycle hooks, etc.) alongside lower-level function and method calls captured by a browser. These two data sets are correlated, and you can switch between the different views and level of details.
+
+You can use the Angular track to better understand how your code runs in the browser, including:
+
+- Determining whether a given code block is part of the Angular application, or whether it belongs to another script running on the same page.
+- Identifying performance bottlenecks and attribute those to specific components or services.
+- Gaining deeper insight into Angular's inner working with a visual breakdown of each change detection cycle.
+
+## Recording a profile
+
+### Enable integration
+
+You can enable Angular profiling in one of two ways:
+
+1. Run `ng.enableProfiling()` in Chrome's console panel, or
+1. Include a call to `enableProfiling()` in your application startup code (imported from `@angular/core`).
+
+NOTE:
+Angular profiling works exclusively in development mode.
+
+Here is an example of how you can enable the integration in the application bootstrap to capture all possible events:
+
+```ts
+import { enableProfiling } from '@angular/core';
+import { bootstrapApplication } from '@angular/platform-browser';
+import { MyApp } from './my-app';
+
+// Turn on profiling *before* bootstrapping your application
+// in order to capture all of the code run on start-up.
+enableProfiling();
+bootstrapApplication(MyApp);
+```
+
+### Record a profile
+
+Use the **Record** button in the Chrome DevTools performance panel:
+
+<img alt="Recording a profile" src="assets/images/best-practices/runtime-performance/recording-profile-in-chrome.png">
+
+See the [Chrome DevTools documentation](https://developer.chrome.com/docs/devtools/performance#record) for more details on recording profiles.
+
+## Interpreting a recorded profile
+
+You can use the "Angular" custom track to quickly identify and diagnose performance issues. The following sections describe some common profiling scenarios.
+
+### Differentiating between your Angular application and other tasks on the same page
+
+As Angular and Chrome data are presented on the separate but correlated tracks, you can see when Angular's application code is executed as opposed to some other browser processing (typically layout and paint) or other scripts running on the same page (in this case the custom Angular track does not have any data):
+
+<img alt="Profile data: Angular vs. 3rd party scripts execution" src="assets/images/best-practices/runtime-performance/profile-angular-vs-3rd-party.png">
+
+This allows you to determine whether further investigations should focus on the Angular application code or on other parts of your codebase or dependencies.
+
+### Color-coding
+
+Angular uses colors in the flame chart graph to distinguish tasks types:
+
+- 🟦 Blue represents TypeScript code written by the application developer (for example: services, component constructors and lifecycle hooks, etc.).
+- 🟪 Purple represents templates code written by the application developer and transformed by the Angular compiler.
+- 🟩 Green represents entry points to the application code and identifies _reasons_ for executing code.
+
+The following examples illustrate the described color-coding in various, real-life recordings.
+
+#### Example: Application bootstrapping
+
+The application bootstrap process usually consists of:
+
+- Triggers marked in blue, such as the call to the `bootstrapApplication`, instantiation of the root component, and initial change detection
+- Various DI services instantiated during bootstrap, marked in green.
+
+<img alt="Profile data: bootstrap application" src="assets/images/best-practices/runtime-performance/profile-bootstrap-application.png">
+
+#### Example: Component execution
+
+One component processing is typically represented as an entry point (blue) followed by its template execution (purple). A template might, in turn, trigger instantiation of directives and execution of lifecycle hooks (green):
+
+<img alt="Profile data: component processing" src="assets/images/best-practices/runtime-performance/profile-component-processing.png">
+
+#### Example: Change detection
+
+A change detection cycle usually consists of one or more data synchronization passes (blue), where each pass traverses a subset of components.
+
+<img alt="Profile data: change detection" src="assets/images/best-practices/runtime-performance/profile-change-detection.png">
+
+With this data visualization, it is possible to immediately identify components that were involved in the change detection and which were skipped (typically the `OnPush` components that were not marked dirty).
+
+Additionally, you can inspect the number of synchronization passes for one change detection. Having more than one synchronization pass suggest that state is updated during change detection. You should avoid this, as it slows down page updates and can even result in infinite loops in the worst cases.
diff --git a/adev-es/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md b/adev-es/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md
index c78d6c2..3aeb46a 100644
--- a/adev-es/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md
+++ b/adev-es/src/content/best-practices/runtime-performance/profiling-with-chrome-devtools.md
@@ -1,100 +1,100 @@
-# Profiling with the Chrome DevTools
+# Perfilado con Chrome DevTools
 
-Angular integrates with the [Chrome DevTools extensibility API](https://developer.chrome.com/docs/devtools/performance/extension) to present framework-specific data and insights directly in the [Chrome DevTools performance panel](https://developer.chrome.com/docs/devtools/performance/overview).
+Angular se integra con la [API de extensibilidad de Chrome DevTools](https://developer.chrome.com/docs/devtools/performance/extension) para presentar datos e información específicos del framework directamente en el [panel de rendimiento de Chrome DevTools](https://developer.chrome.com/docs/devtools/performance/overview).
 
-With the integration enabled, you can [record a performance profile](https://developer.chrome.com/docs/devtools/performance#record) containing two sets of data:
+Con la integración habilitada, puedes [grabar un perfil de rendimiento](https://developer.chrome.com/docs/devtools/performance#record) que contiene dos conjuntos de datos:
 
-- Standard performance entries based on Chrome's understanding of your code executing in a browser, and
-- Angular-specific entries contributed by the framework's runtime.
+- Entradas de rendimiento estándar basadas en la comprensión de Chrome de tu código ejecutándose en un navegador, y
+- Entradas específicas de Angular contribuidas por el tiempo de ejecución del framework.
 
-Both sets of data are presented together on the same tab, but on separate tracks:
+Ambos conjuntos de datos se presentan juntos en la misma pestaña, pero en pistas separadas:
 
-<img alt="Angular custom track in Chrome DevTools profiler" src="assets/images/best-practices/runtime-performance/angular-perf-in-chrome.png">
+<img alt="Pista personalizada de Angular en el perfilador de Chrome DevTools" src="assets/images/best-practices/runtime-performance/angular-perf-in-chrome.png">
 
-Angular-specific data are expressed in terms of framework concepts (components, change detection, lifecycle hooks, etc.) alongside lower-level function and method calls captured by a browser. These two data sets are correlated, and you can switch between the different views and level of details.
+Los datos específicos de Angular se expresan en términos de conceptos del framework (componentes, change detection, hooks de ciclo de vida, etc.) junto con llamadas de funciones y métodos de nivel más bajo capturadas por un navegador. Estos dos conjuntos de datos están correlacionados, y puedes cambiar entre las diferentes vistas y niveles de detalle.
 
-You can use the Angular track to better understand how your code runs in the browser, including:
+Puedes usar la pista de Angular para entender mejor cómo se ejecuta tu código en el navegador, incluyendo:
 
-- Determining whether a given code block is part of the Angular application, or whether it belongs to another script running on the same page.
-- Identifying performance bottlenecks and attribute those to specific components or services.
-- Gaining deeper insight into Angular's inner working with a visual breakdown of each change detection cycle.
+- Determinar si un bloque de código dado es parte de la aplicación Angular, o si pertenece a otro script ejecutándose en la misma página.
+- Identificar cuellos de botella de rendimiento y atribuirlos a componentes o servicios específicos.
+- Obtener una visión más profunda del funcionamiento interno de Angular con un desglose visual de cada ciclo de change detection.
 
-## Recording a profile
+## Grabando un perfil
 
-### Enable integration
+### Habilitar integración
 
-You can enable Angular profiling in one of two ways:
+Puedes habilitar el perfilado de Angular de dos maneras:
 
-1. Run `ng.enableProfiling()` in Chrome's console panel, or
-1. Include a call to `enableProfiling()` in your application startup code (imported from `@angular/core`).
+1. Ejecutar `ng.enableProfiling()` en el panel de consola de Chrome, o
+1. Incluir una llamada a `enableProfiling()` en el código de inicio de tu aplicación (importado desde `@angular/core`).
 
-NOTE:
-Angular profiling works exclusively in development mode.
+NOTA:
+El perfilado de Angular funciona exclusivamente en modo de desarrollo.
 
-Here is an example of how you can enable the integration in the application bootstrap to capture all possible events:
+Aquí hay un ejemplo de cómo puedes habilitar la integración en el bootstrap de la aplicación para capturar todos los eventos posibles:
 
 ```ts
 import { enableProfiling } from '@angular/core';
 import { bootstrapApplication } from '@angular/platform-browser';
 import { MyApp } from './my-app';
 
-// Turn on profiling *before* bootstrapping your application
-// in order to capture all of the code run on start-up.
+// Activa el perfilado *antes* de iniciar tu aplicación
+// para capturar todo el código ejecutado al inicio.
 enableProfiling();
 bootstrapApplication(MyApp);
 ```
 
-### Record a profile
+### Grabar un perfil
 
-Use the **Record** button in the Chrome DevTools performance panel:
+Usa el botón **Record** en el panel de rendimiento de Chrome DevTools:
 
-<img alt="Recording a profile" src="assets/images/best-practices/runtime-performance/recording-profile-in-chrome.png">
+<img alt="Grabando un perfil" src="assets/images/best-practices/runtime-performance/recording-profile-in-chrome.png">
 
-See the [Chrome DevTools documentation](https://developer.chrome.com/docs/devtools/performance#record) for more details on recording profiles.
+Consulta la [documentación de Chrome DevTools](https://developer.chrome.com/docs/devtools/performance#record) para más detalles sobre la grabación de perfiles.
 
-## Interpreting a recorded profile
+## Interpretando un perfil grabado
 
-You can use the "Angular" custom track to quickly identify and diagnose performance issues. The following sections describe some common profiling scenarios.
+Puedes usar la pista personalizada "Angular" para identificar y diagnosticar rápidamente problemas de rendimiento. Las siguientes secciones describen algunos escenarios comunes de perfilado.
 
-### Differentiating between your Angular application and other tasks on the same page
+### Diferenciando entre tu aplicación Angular y otras tareas en la misma página
 
-As Angular and Chrome data are presented on the separate but correlated tracks, you can see when Angular's application code is executed as opposed to some other browser processing (typically layout and paint) or other scripts running on the same page (in this case the custom Angular track does not have any data):
+Como los datos de Angular y Chrome se presentan en pistas separadas pero correlacionadas, puedes ver cuándo se ejecuta el código de la aplicación Angular en oposición a algún otro procesamiento del navegador (típicamente layout y paint) u otros scripts ejecutándose en la misma página (en este caso la pista personalizada de Angular no tiene ningún dato):
 
-<img alt="Profile data: Angular vs. 3rd party scripts execution" src="assets/images/best-practices/runtime-performance/profile-angular-vs-3rd-party.png">
+<img alt="Datos de perfil: ejecución de Angular vs. scripts de terceros" src="assets/images/best-practices/runtime-performance/profile-angular-vs-3rd-party.png">
 
-This allows you to determine whether further investigations should focus on the Angular application code or on other parts of your codebase or dependencies.
+Esto te permite determinar si investigaciones posteriores deben enfocarse en el código de la aplicación Angular o en otras partes de tu código base o dependencias.
 
-### Color-coding
+### Codificación por colores
 
-Angular uses colors in the flame chart graph to distinguish tasks types:
+Angular usa colores en el gráfico de llamas para distinguir tipos de tareas:
 
-- 🟦 Blue represents TypeScript code written by the application developer (for example: services, component constructors and lifecycle hooks, etc.).
-- 🟪 Purple represents templates code written by the application developer and transformed by the Angular compiler.
-- 🟩 Green represents entry points to the application code and identifies _reasons_ for executing code.
+- 🟦 Azul representa código TypeScript escrito por el desarrollador de la aplicación (por ejemplo: servicios, constructores de componentes y hooks de ciclo de vida, etc.).
+- 🟪 Púrpura representa código de plantillas escrito por el desarrollador de la aplicación y transformado por el compilador de Angular.
+- 🟩 Verde representa puntos de entrada al código de la aplicación e identifica _razones_ para ejecutar código.
 
-The following examples illustrate the described color-coding in various, real-life recordings.
+Los siguientes ejemplos ilustran la codificación por colores descrita en varias grabaciones de la vida real.
 
-#### Example: Application bootstrapping
+#### Ejemplo: Bootstrap de la aplicación
 
-The application bootstrap process usually consists of:
+El proceso de bootstrap de la aplicación usualmente consiste en:
 
-- Triggers marked in blue, such as the call to the `bootstrapApplication`, instantiation of the root component, and initial change detection
-- Various DI services instantiated during bootstrap, marked in green.
+- Disparadores marcados en azul, como la llamada a `bootstrapApplication`, instanciación del componente raíz, y change detection inicial
+- Varios servicios de DI instanciados durante el bootstrap, marcados en verde.
 
-<img alt="Profile data: bootstrap application" src="assets/images/best-practices/runtime-performance/profile-bootstrap-application.png">
+<img alt="Datos de perfil: bootstrap de la aplicación" src="assets/images/best-practices/runtime-performance/profile-bootstrap-application.png">
 
-#### Example: Component execution
+#### Ejemplo: Ejecución de componente
 
-One component processing is typically represented as an entry point (blue) followed by its template execution (purple). A template might, in turn, trigger instantiation of directives and execution of lifecycle hooks (green):
+El procesamiento de un componente típicamente se representa como un punto de entrada (azul) seguido de su ejecución de plantilla (púrpura). Una plantilla puede, a su vez, disparar la instanciación de directivas y ejecución de hooks de ciclo de vida (verde):
 
-<img alt="Profile data: component processing" src="assets/images/best-practices/runtime-performance/profile-component-processing.png">
+<img alt="Datos de perfil: procesamiento de componente" src="assets/images/best-practices/runtime-performance/profile-component-processing.png">
 
-#### Example: Change detection
+#### Ejemplo: Change detection
 
-A change detection cycle usually consists of one or more data synchronization passes (blue), where each pass traverses a subset of components.
+Un ciclo de change detection usualmente consiste en uno o más pases de sincronización de datos (azul), donde cada pase recorre un subconjunto de componentes.
 
-<img alt="Profile data: change detection" src="assets/images/best-practices/runtime-performance/profile-change-detection.png">
+<img alt="Datos de perfil: change detection" src="assets/images/best-practices/runtime-performance/profile-change-detection.png">
 
-With this data visualization, it is possible to immediately identify components that were involved in the change detection and which were skipped (typically the `OnPush` components that were not marked dirty).
+Con esta visualización de datos, es posible identificar inmediatamente los componentes que estuvieron involucrados en el change detection y cuáles fueron omitidos (típicamente los componentes `OnPush` que no fueron marcados como dirty).
 
-Additionally, you can inspect the number of synchronization passes for one change detection. Having more than one synchronization pass suggest that state is updated during change detection. You should avoid this, as it slows down page updates and can even result in infinite loops in the worst cases.
+Adicionalmente, puedes inspeccionar el número de pases de sincronización para un change detection. Tener más de un pase de sincronización sugiere que el estado se actualiza durante el change detection. Debes evitar esto, ya que ralentiza las actualizaciones de la página y puede incluso resultar en bucles infinitos en los peores casos.
diff --git a/adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.en.md b/adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.en.md
new file mode 100644
index 0000000..64e984d
--- /dev/null
+++ b/adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.en.md
@@ -0,0 +1,132 @@
+# Skipping component subtrees
+
+JavaScript, by default, uses mutable data structures that you can reference from multiple different components. Angular runs change detection over your entire component tree to make sure that the most up-to-date state of your data structures is reflected in the DOM.
+
+Change detection is sufficiently fast for most applications. However, when an application has an especially large component tree, running change detection across the whole application can cause performance issues. You can address this by configuring change detection to only run on a subset of the component tree.
+
+If you are confident that a part of the application is not affected by a state change, you can use [OnPush](/api/core/ChangeDetectionStrategy) to skip change detection in an entire component subtree.
+
+## Using `OnPush`
+
+OnPush change detection instructs Angular to run change detection for a component subtree **only** when:
+
+* The root component of the subtree receives new inputs as the result of a template binding. Angular compares the current and past value of the input with `==`.
+* Angular handles an event _(for example using event binding, output binding, or `@HostListener` )_ in the subtree's root component or any of its children whether they are using OnPush change detection or not.
+
+You can set the change detection strategy of a component to `OnPush` in the `@Component` decorator:
+
+```ts
+import { ChangeDetectionStrategy, Component } from '@angular/core';
+@Component({
+  changeDetection: ChangeDetectionStrategy.OnPush,
+})
+export class MyComponent {}
+```
+
+## Common change detection scenarios
+
+This section examines several common change detection scenarios to illustrate Angular's behavior.
+
+### An event is handled by a component with default change detection
+
+If Angular handles an event within a component without `OnPush` strategy, the framework executes change detection on the entire component tree. Angular will skip descendant component subtrees with roots using `OnPush`, which have not received new inputs.
+
+As an example, if we set the change detection strategy of `MainComponent` to `OnPush` and the user interacts with a component outside the subtree with root `MainComponent`, Angular will check all the pink components from the diagram below (`AppComponent`, `HeaderComponent`, `SearchComponent`, `ButtonComponent`) unless `MainComponent` receives new inputs:
+
+```mermaid
+graph TD;
+    app[AppComponent] --- header[HeaderComponent];
+    app --- main["MainComponent (OnPush)"];
+    header --- search[SearchComponent];
+    header --- button[ButtonComponent];
+    main --- login["LoginComponent (OnPush)"];
+    main --- details[DetailsComponent];
+    event>Event] --- search
+
+class app checkedNode
+class header checkedNode
+class button checkedNode
+class search checkedNode
+class event eventNode
+```
+
+## An event is handled by a component with OnPush
+
+If Angular handles an event within a component with OnPush strategy, the framework will execute change detection within the entire component tree. Angular will ignore component subtrees with roots using OnPush, which have not received new inputs and are outside the component which handled the event.
+
+As an example, if Angular handles an event within `MainComponent`, the framework will run change detection in the entire component tree. Angular will ignore the subtree with root `LoginComponent` because it has `OnPush` and the event happened outside of its scope.
+
+```mermaid
+graph TD;
+    app[AppComponent] --- header[HeaderComponent];
+    app --- main["MainComponent (OnPush)"];
+    header --- search[SearchComponent];
+    header --- button[ButtonComponent];
+    main --- login["LoginComponent (OnPush)"];
+    main --- details[DetailsComponent];
+    event>Event] --- main
+
+class app checkedNode
+class header checkedNode
+class button checkedNode
+class search checkedNode
+class main checkedNode
+class details checkedNode
+class event eventNode
+```
+
+## An event is handled by a descendant of a component with OnPush
+
+If Angular handles an event in a component with OnPush, the framework will execute change detection in the entire component tree, including the component’s ancestors.
+
+As an example, in the diagram below, Angular handles an event in `LoginComponent` which uses OnPush. Angular will invoke change detection in the entire component subtree including `MainComponent` (`LoginComponent`’s parent), even though `MainComponent` has `OnPush` as well. Angular checks `MainComponent` as well because `LoginComponent` is part of its view.
+
+```mermaid
+graph TD;
+    app[AppComponent] --- header[HeaderComponent];
+    app --- main["MainComponent (OnPush)"];
+    header --- search[SearchComponent];
+    header --- button[ButtonComponent];
+    main --- login["LoginComponent (OnPush)"];
+    main --- details[DetailsComponent];
+    event>Event] --- login
+
+class app checkedNode
+class header checkedNode
+class button checkedNode
+class search checkedNode
+class login checkedNode
+class main checkedNode
+class details checkedNode
+class event eventNode
+```
+
+## New inputs to component with OnPush
+
+Angular will run change detection within a child component with `OnPush` when setting an input property as result of a template binding.
+
+For example, in the diagram below, `AppComponent` passes a new input to `MainComponent`, which has `OnPush`. Angular will run change detection in `MainComponent` but will not run change detection in `LoginComponent`, which also has `OnPush`, unless it receives new inputs as well.
+
+```mermaid
+graph TD;
+    app[AppComponent] --- header[HeaderComponent];
+    app --- main["MainComponent (OnPush)"];
+    header --- search[SearchComponent];
+    header --- button[ButtonComponent];
+    main --- login["LoginComponent (OnPush)"];
+    main --- details[DetailsComponent];
+    event>Parent passes new input to MainComponent]
+
+class app checkedNode
+class header checkedNode
+class button checkedNode
+class search checkedNode
+class main checkedNode
+class details checkedNode
+class event eventNode
+```
+
+## Edge cases
+
+* **Modifying input properties in TypeScript code**. When you use an API like `@ViewChild` or `@ContentChild` to get a reference to a component in TypeScript and manually modify an `@Input` property, Angular will not automatically run change detection for OnPush components. If you need Angular to run change detection, you can inject `ChangeDetectorRef` in your component and call `changeDetectorRef.markForCheck()` to tell Angular to schedule a change detection.
+* **Modifying object references**. In case an input receives a mutable object as value and you modify the object but preserve the reference, Angular will not invoke change detection. That’s the expected behavior because the previous and the current value of the input point to the same reference.
diff --git a/adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.md b/adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.md
index 64e984d..3dff507 100644
--- a/adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.md
+++ b/adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.md
@@ -1,19 +1,19 @@
-# Skipping component subtrees
+# Omitiendo subárboles de componentes
 
-JavaScript, by default, uses mutable data structures that you can reference from multiple different components. Angular runs change detection over your entire component tree to make sure that the most up-to-date state of your data structures is reflected in the DOM.
+JavaScript, por defecto, usa estructuras de datos mutables que puedes referenciar desde múltiples componentes diferentes. Angular ejecuta change detection sobre todo tu árbol de componentes para asegurarse de que el estado más actualizado de tus estructuras de datos se refleje en el DOM.
 
-Change detection is sufficiently fast for most applications. However, when an application has an especially large component tree, running change detection across the whole application can cause performance issues. You can address this by configuring change detection to only run on a subset of the component tree.
+El change detection es suficientemente rápido para la mayoría de las aplicaciones. Sin embargo, cuando una aplicación tiene un árbol de componentes especialmente grande, ejecutar change detection en toda la aplicación puede causar problemas de rendimiento. Puedes abordar esto configurando el change detection para que solo se ejecute en un subconjunto del árbol de componentes.
 
-If you are confident that a part of the application is not affected by a state change, you can use [OnPush](/api/core/ChangeDetectionStrategy) to skip change detection in an entire component subtree.
+Si confías en que una parte de la aplicación no está afectada por un cambio de estado, puedes usar [OnPush](/api/core/ChangeDetectionStrategy) para omitir change detection en un subárbol completo de componentes.
 
-## Using `OnPush`
+## Usando `OnPush`
 
-OnPush change detection instructs Angular to run change detection for a component subtree **only** when:
+El change detection OnPush le indica a Angular que ejecute change detection para un subárbol de componentes **solo** cuando:
 
-* The root component of the subtree receives new inputs as the result of a template binding. Angular compares the current and past value of the input with `==`.
-* Angular handles an event _(for example using event binding, output binding, or `@HostListener` )_ in the subtree's root component or any of its children whether they are using OnPush change detection or not.
+* El componente raíz del subárbol recibe nuevas entradas como resultado de un enlace de plantilla. Angular compara el valor actual y pasado de la entrada con `==`.
+* Angular maneja un evento _(por ejemplo usando enlace de evento, enlace de salida, o `@HostListener`)_ en el componente raíz del subárbol o cualquiera de sus hijos, ya sea que estén usando change detection OnPush o no.
 
-You can set the change detection strategy of a component to `OnPush` in the `@Component` decorator:
+Puedes establecer la estrategia de change detection de un componente a `OnPush` en el decorador `@Component`:
 
 ```ts
 import { ChangeDetectionStrategy, Component } from '@angular/core';
@@ -23,15 +23,15 @@ import { ChangeDetectionStrategy, Component } from '@angular/core';
 export class MyComponent {}
 ```
 
-## Common change detection scenarios
+## Escenarios comunes de change detection
 
-This section examines several common change detection scenarios to illustrate Angular's behavior.
+Esta sección examina varios escenarios comunes de change detection para ilustrar el comportamiento de Angular.
 
-### An event is handled by a component with default change detection
+### Un evento es manejado por un componente con change detection predeterminado
 
-If Angular handles an event within a component without `OnPush` strategy, the framework executes change detection on the entire component tree. Angular will skip descendant component subtrees with roots using `OnPush`, which have not received new inputs.
+Si Angular maneja un evento dentro de un componente sin estrategia `OnPush`, el framework ejecuta change detection en todo el árbol de componentes. Angular omitirá subárboles de componentes descendientes con raíces usando `OnPush`, que no han recibido nuevas entradas.
 
-As an example, if we set the change detection strategy of `MainComponent` to `OnPush` and the user interacts with a component outside the subtree with root `MainComponent`, Angular will check all the pink components from the diagram below (`AppComponent`, `HeaderComponent`, `SearchComponent`, `ButtonComponent`) unless `MainComponent` receives new inputs:
+Por ejemplo, si establecemos la estrategia de change detection de `MainComponent` a `OnPush` y el usuario interactúa con un componente fuera del subárbol con raíz `MainComponent`, Angular verificará todos los componentes rosa del diagrama de abajo (`AppComponent`, `HeaderComponent`, `SearchComponent`, `ButtonComponent`) a menos que `MainComponent` reciba nuevas entradas:
 
 ```mermaid
 graph TD;
@@ -50,11 +50,11 @@ class search checkedNode
 class event eventNode
 ```
 
-## An event is handled by a component with OnPush
+## Un evento es manejado por un componente con OnPush
 
-If Angular handles an event within a component with OnPush strategy, the framework will execute change detection within the entire component tree. Angular will ignore component subtrees with roots using OnPush, which have not received new inputs and are outside the component which handled the event.
+Si Angular maneja un evento dentro de un componente con estrategia OnPush, el framework ejecutará change detection dentro de todo el árbol de componentes. Angular ignorará subárboles de componentes con raíces usando OnPush, que no han recibido nuevas entradas y están fuera del componente que manejó el evento.
 
-As an example, if Angular handles an event within `MainComponent`, the framework will run change detection in the entire component tree. Angular will ignore the subtree with root `LoginComponent` because it has `OnPush` and the event happened outside of its scope.
+Por ejemplo, si Angular maneja un evento dentro de `MainComponent`, el framework ejecutará change detection en todo el árbol de componentes. Angular ignorará el subárbol con raíz `LoginComponent` porque tiene `OnPush` y el evento ocurrió fuera de su alcance.
 
 ```mermaid
 graph TD;
@@ -75,11 +75,11 @@ class details checkedNode
 class event eventNode
 ```
 
-## An event is handled by a descendant of a component with OnPush
+## Un evento es manejado por un descendiente de un componente con OnPush
 
-If Angular handles an event in a component with OnPush, the framework will execute change detection in the entire component tree, including the component’s ancestors.
+Si Angular maneja un evento en un componente con OnPush, el framework ejecutará change detection en todo el árbol de componentes, incluidos los ancestros del componente.
 
-As an example, in the diagram below, Angular handles an event in `LoginComponent` which uses OnPush. Angular will invoke change detection in the entire component subtree including `MainComponent` (`LoginComponent`’s parent), even though `MainComponent` has `OnPush` as well. Angular checks `MainComponent` as well because `LoginComponent` is part of its view.
+Por ejemplo, en el diagrama de abajo, Angular maneja un evento en `LoginComponent` que usa OnPush. Angular invocará change detection en todo el subárbol de componentes incluyendo `MainComponent` (padre de `LoginComponent`), aunque `MainComponent` también tenga `OnPush`. Angular verifica `MainComponent` también porque `LoginComponent` es parte de su vista.
 
 ```mermaid
 graph TD;
@@ -101,11 +101,11 @@ class details checkedNode
 class event eventNode
 ```
 
-## New inputs to component with OnPush
+## Nuevas entradas a componente con OnPush
 
-Angular will run change detection within a child component with `OnPush` when setting an input property as result of a template binding.
+Angular ejecutará change detection dentro de un componente hijo con `OnPush` cuando se establece una propiedad de entrada como resultado de un enlace de plantilla.
 
-For example, in the diagram below, `AppComponent` passes a new input to `MainComponent`, which has `OnPush`. Angular will run change detection in `MainComponent` but will not run change detection in `LoginComponent`, which also has `OnPush`, unless it receives new inputs as well.
+Por ejemplo, en el diagrama de abajo, `AppComponent` pasa una nueva entrada a `MainComponent`, que tiene `OnPush`. Angular ejecutará change detection en `MainComponent` pero no ejecutará change detection en `LoginComponent`, que también tiene `OnPush`, a menos que reciba nuevas entradas también.
 
 ```mermaid
 graph TD;
@@ -126,7 +126,7 @@ class details checkedNode
 class event eventNode
 ```
 
-## Edge cases
+## Casos extremos
 
-* **Modifying input properties in TypeScript code**. When you use an API like `@ViewChild` or `@ContentChild` to get a reference to a component in TypeScript and manually modify an `@Input` property, Angular will not automatically run change detection for OnPush components. If you need Angular to run change detection, you can inject `ChangeDetectorRef` in your component and call `changeDetectorRef.markForCheck()` to tell Angular to schedule a change detection.
-* **Modifying object references**. In case an input receives a mutable object as value and you modify the object but preserve the reference, Angular will not invoke change detection. That’s the expected behavior because the previous and the current value of the input point to the same reference.
+* **Modificar propiedades de entrada en código TypeScript**. Cuando usas una API como `@ViewChild` o `@ContentChild` para obtener una referencia a un componente en TypeScript y modificas manualmente una propiedad `@Input`, Angular no ejecutará automáticamente change detection para componentes OnPush. Si necesitas que Angular ejecute change detection, puedes inyectar `ChangeDetectorRef` en tu componente y llamar a `changeDetectorRef.markForCheck()` para indicarle a Angular que programe un change detection.
+* **Modificar referencias de objetos**. En caso de que una entrada reciba un objeto mutable como valor y modifiques el objeto pero preserves la referencia, Angular no invocará change detection. Ese es el comportamiento esperado porque el valor anterior y el actual de la entrada apuntan a la misma referencia.
diff --git a/adev-es/src/content/best-practices/runtime-performance/slow-computations.en.md b/adev-es/src/content/best-practices/runtime-performance/slow-computations.en.md
new file mode 100644
index 0000000..38f8aab
--- /dev/null
+++ b/adev-es/src/content/best-practices/runtime-performance/slow-computations.en.md
@@ -0,0 +1,26 @@
+# Slow computations
+
+On every change detection cycle, Angular synchronously:
+
+* Evaluates all template expressions in all components, unless specified otherwise, based on that each component's detection strategy
+* Executes the `ngDoCheck`, `ngAfterContentChecked`, `ngAfterViewChecked`, and `ngOnChanges` lifecycle hooks.
+A single slow computation within a template or a lifecycle hook can slow down the entire change detection process because Angular runs the computations sequentially.
+
+## Identifying slow computations
+
+You can identify heavy computations with Angular DevTools’ profiler. In the performance timeline, click a bar to preview a particular change detection cycle. This displays a bar chart, which shows how long the framework spent in change detection for each component. When you click a component, you can preview how long Angular spent  evaluating its template and lifecycle hooks.
+
+<img alt="Angular DevTools profiler preview showing slow computation" src="assets/images/best-practices/runtime-performance/slow-computations.png">
+
+For example, in the preceding screenshot, the second recorded change detection cycle is selected. Angular spent over 573 ms on this cycle, with the most time spent in the `EmployeeListComponent`. In the details panel, you can see that Angular spent over 297 ms evaluating the template of the `EmployeeListComponent`.
+
+## Optimizing slow computations
+
+Here are several techniques to remove slow computations:
+
+* **Optimizing the underlying algorithm**. This is the recommended approach. If you can speed up the algorithm that is causing the problem, you can speed up the entire change detection mechanism.
+* **Caching using pure pipes**. You can move the heavy computation to a pure [pipe](guide/pipes). Angular reevaluates a pure pipe only if it detects that its inputs have changed, compared to the previous time Angular called it.
+* **Using memoization**. [Memoization](https://en.wikipedia.org/wiki/Memoization) is a similar technique to pure pipes, with the difference that pure pipes preserve only the last result from the computation where memoization could store multiple results.
+* **Avoid repaints/reflows in lifecycle hooks**. Certain [operations](https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/) cause the browser to either synchronously recalculate the layout of the page or re-render it. Since reflows and repaints are generally slow, you want to avoid performing them in every change detection cycle.
+
+Pure pipes and memoization have different trade-offs. Pure pipes are an Angular built-in concept compared to memoization, which is a general software engineering practice for caching function results. The memory overhead of memoization could be significant if you invoke the heavy computation frequently with different arguments.
diff --git a/adev-es/src/content/best-practices/runtime-performance/slow-computations.md b/adev-es/src/content/best-practices/runtime-performance/slow-computations.md
index 38f8aab..a6ecab5 100644
--- a/adev-es/src/content/best-practices/runtime-performance/slow-computations.md
+++ b/adev-es/src/content/best-practices/runtime-performance/slow-computations.md
@@ -1,26 +1,26 @@
-# Slow computations
+# Computaciones lentas
 
-On every change detection cycle, Angular synchronously:
+En cada ciclo de change detection, Angular sincrónicamente:
 
-* Evaluates all template expressions in all components, unless specified otherwise, based on that each component's detection strategy
-* Executes the `ngDoCheck`, `ngAfterContentChecked`, `ngAfterViewChecked`, and `ngOnChanges` lifecycle hooks.
-A single slow computation within a template or a lifecycle hook can slow down the entire change detection process because Angular runs the computations sequentially.
+* Evalúa todas las expresiones de plantilla en todos los componentes, a menos que se especifique lo contrario, basándose en la estrategia de detección de cada componente
+* Ejecuta los hooks de ciclo de vida `ngDoCheck`, `ngAfterContentChecked`, `ngAfterViewChecked`, y `ngOnChanges`.
+Una sola computación lenta dentro de una plantilla o un hook de ciclo de vida puede ralentizar todo el proceso de change detection porque Angular ejecuta las computaciones secuencialmente.
 
-## Identifying slow computations
+## Identificando computaciones lentas
 
-You can identify heavy computations with Angular DevTools’ profiler. In the performance timeline, click a bar to preview a particular change detection cycle. This displays a bar chart, which shows how long the framework spent in change detection for each component. When you click a component, you can preview how long Angular spent  evaluating its template and lifecycle hooks.
+Puedes identificar computaciones pesadas con el perfilador de Angular DevTools. En la línea de tiempo de rendimiento, haz clic en una barra para previsualizar un ciclo particular de change detection. Esto muestra un gráfico de barras, que muestra cuánto tiempo pasó el framework en change detection para cada componente. Cuando haces clic en un componente, puedes previsualizar cuánto tiempo pasó Angular evaluando su plantilla y hooks de ciclo de vida.
 
-<img alt="Angular DevTools profiler preview showing slow computation" src="assets/images/best-practices/runtime-performance/slow-computations.png">
+<img alt="Vista previa del perfilador de Angular DevTools mostrando computación lenta" src="assets/images/best-practices/runtime-performance/slow-computations.png">
 
-For example, in the preceding screenshot, the second recorded change detection cycle is selected. Angular spent over 573 ms on this cycle, with the most time spent in the `EmployeeListComponent`. In the details panel, you can see that Angular spent over 297 ms evaluating the template of the `EmployeeListComponent`.
+Por ejemplo, en la captura de pantalla anterior, el segundo ciclo de change detection grabado está seleccionado. Angular pasó más de 573 ms en este ciclo, con la mayor parte del tiempo gastado en el `EmployeeListComponent`. En el panel de detalles, puedes ver que Angular pasó más de 297 ms evaluando la plantilla del `EmployeeListComponent`.
 
-## Optimizing slow computations
+## Optimizando computaciones lentas
 
-Here are several techniques to remove slow computations:
+Aquí hay varias técnicas para eliminar computaciones lentas:
 
-* **Optimizing the underlying algorithm**. This is the recommended approach. If you can speed up the algorithm that is causing the problem, you can speed up the entire change detection mechanism.
-* **Caching using pure pipes**. You can move the heavy computation to a pure [pipe](guide/pipes). Angular reevaluates a pure pipe only if it detects that its inputs have changed, compared to the previous time Angular called it.
-* **Using memoization**. [Memoization](https://en.wikipedia.org/wiki/Memoization) is a similar technique to pure pipes, with the difference that pure pipes preserve only the last result from the computation where memoization could store multiple results.
-* **Avoid repaints/reflows in lifecycle hooks**. Certain [operations](https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/) cause the browser to either synchronously recalculate the layout of the page or re-render it. Since reflows and repaints are generally slow, you want to avoid performing them in every change detection cycle.
+* **Optimizar el algoritmo subyacente**. Este es el enfoque recomendado. Si puedes acelerar el algoritmo que está causando el problema, puedes acelerar todo el mecanismo de change detection.
+* **Caching usando pipes puros**. Puedes mover la computación pesada a un [pipe](guide/pipes) puro. Angular reevalúa un pipe puro solo si detecta que sus entradas han cambiado, comparado con la vez anterior que Angular lo llamó.
+* **Usando memoización**. La [memoización](https://en.wikipedia.org/wiki/Memoization) es una técnica similar a los pipes puros, con la diferencia de que los pipes puros preservan solo el último resultado de la computación donde la memoización podría almacenar múltiples resultados.
+* **Evitar repaints/reflows en hooks de ciclo de vida**. Ciertas [operaciones](https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/) causan que el navegador recalcule sincrónicamente el layout de la página o la vuelva a renderizar. Ya que los reflows y repaints son generalmente lentos, quieres evitar realizarlos en cada ciclo de change detection.
 
-Pure pipes and memoization have different trade-offs. Pure pipes are an Angular built-in concept compared to memoization, which is a general software engineering practice for caching function results. The memory overhead of memoization could be significant if you invoke the heavy computation frequently with different arguments.
+Los pipes puros y la memoización tienen diferentes compensaciones. Los pipes puros son un concepto integrado de Angular comparado con la memoización, que es una práctica general de ingeniería de software para cachear resultados de funciones. La sobrecarga de memoria de la memoización podría ser significativa si invocas la computación pesada frecuentemente con diferentes argumentos.
diff --git a/adev-es/src/content/best-practices/runtime-performance/zone-pollution.en.md b/adev-es/src/content/best-practices/runtime-performance/zone-pollution.en.md
new file mode 100644
index 0000000..e232ec0
--- /dev/null
+++ b/adev-es/src/content/best-practices/runtime-performance/zone-pollution.en.md
@@ -0,0 +1,123 @@
+# Resolving zone pollution
+
+**Zone.js** is a signaling mechanism that Angular uses to detect when an application state might have changed. It captures asynchronous operations like `setTimeout`, network requests, and event listeners. Angular schedules change detection based on signals from Zone.js.
+
+In some cases scheduled [tasks](https://developer.mozilla.org/docs/Web/API/HTML_DOM_API/Microtask_guide#tasks) or [microtasks](https://developer.mozilla.org/docs/Web/API/HTML_DOM_API/Microtask_guide#microtasks) don’t make any changes in the data model, which makes running change detection unnecessary. Common examples are:
+
+* `requestAnimationFrame`, `setTimeout` or `setInterval`
+* Task or microtask scheduling by third-party libraries
+
+This section covers how to identify such conditions, and how to run code outside the Angular zone to avoid unnecessary change detection calls.
+
+## Identifying unnecessary change detection calls
+
+You can detect unnecessary change detection calls using Angular DevTools. Often they appear as consecutive bars in the profiler’s timeline with source `setTimeout`, `setInterval`, `requestAnimationFrame`, or an event handler. When you have limited calls within your application of these APIs, the change detection invocation is usually caused by a third-party library.
+
+<img alt="Angular DevTools profiler preview showing Zone pollution" src="assets/images/best-practices/runtime-performance/zone-pollution.png">
+
+In the image above, there is a series of change detection calls triggered by event handlers associated with an element. That’s a common challenge when using third-party, non-native Angular components, which do not alter the default behavior of `NgZone`.
+
+## Run tasks outside `NgZone`
+
+In such cases, you can instruct Angular to avoid calling change detection for tasks scheduled by a given piece of code using [NgZone](/api/core/NgZone).
+
+<docs-code header="Run outside of the Zone" language='ts' linenums>
+import { Component, NgZone, OnInit } from '@angular/core';
+
+@Component(...)
+class AppComponent implements OnInit {
+  private ngZone = inject(NgZone);
+
+  ngOnInit() {
+    this.ngZone.runOutsideAngular(() => setInterval(pollForUpdates), 500);
+  }
+}
+</docs-code>
+
+The preceding snippet instructs Angular to call `setInterval` outside the Angular Zone and skip running change detection after `pollForUpdates` runs.
+
+Third-party libraries commonly trigger unnecessary change detection cycles when their APIs are invoked within the Angular zone. This phenomenon particularly affects libraries that set up event listeners or initiate other tasks (such as timers, XHR requests, etc.). Avoid these extra cycles by calling library APIs outside the Angular zone:
+
+<docs-code header="Move the plot initialization outside of the Zone" language='ts' linenums>
+import { Component, NgZone, OnInit } from '@angular/core';
+import * as Plotly from 'plotly.js-dist-min';
+
+@Component(...)
+class AppComponent implements OnInit {
+  private ngZone = inject(NgZone);
+
+  ngOnInit() {
+    this.ngZone.runOutsideAngular(() => {
+      Plotly.newPlot('chart', data);
+    });
+  }
+}
+</docs-code>
+
+Running `Plotly.newPlot('chart', data);` within `runOutsideAngular` instructs the framework that it shouldn’t run change detection after the execution of tasks scheduled by the initialization logic.
+
+For example, if `Plotly.newPlot('chart', data)` adds event listeners to a DOM element, Angular does not run change detection after the execution of their handlers.
+
+But sometimes, you may need to listen to events dispatched by third-party APIs. In such cases, it's important to remember that those event listeners will also execute outside of the Angular zone if the initialization logic was done there:
+
+<docs-code header="Check whether the handler is called outside of the Zone" language='ts' linenums>
+import { Component, NgZone, OnInit, output } from '@angular/core';
+import * as Plotly from 'plotly.js-dist-min';
+
+@Component(...)
+class AppComponent implements OnInit {
+  private ngZone = inject(NgZone);
+
+  plotlyClick = output<Plotly.PlotMouseEvent>();
+
+  ngOnInit() {
+    this.ngZone.runOutsideAngular(() => {
+      this.createPlotly();
+    });
+  }
+
+  private async createPlotly() {
+    const plotly = await Plotly.newPlot('chart', data);
+
+    plotly.on('plotly_click', (event: Plotly.PlotMouseEvent) => {
+      // This handler will be called outside of the Angular zone because
+      // the initialization logic is also called outside of the zone. To check
+      // whether we're in the Angular zone, we can call the following:
+      console.log(NgZone.isInAngularZone());
+      this.plotlyClick.emit(event);
+    });
+  }
+}
+</docs-code>
+
+If you need to dispatch events to parent components and execute specific view update logic, you should consider re-entering the Angular zone to instruct the framework to run change detection or run change detection manually:
+
+<docs-code header="Re-enter the Angular zone when dispatching event" language='ts' linenums>
+import { Component, NgZone, OnInit, output } from '@angular/core';
+import * as Plotly from 'plotly.js-dist-min';
+
+@Component(...)
+class AppComponent implements OnInit {
+  private ngZone = inject(NgZone);
+
+  plotlyClick = output<Plotly.PlotMouseEvent>();
+
+  ngOnInit() {
+    this.ngZone.runOutsideAngular(() => {
+      this.createPlotly();
+    });
+  }
+
+  private async createPlotly() {
+    const plotly = await Plotly.newPlot('chart', data);
+
+    plotly.on('plotly_click', (event: Plotly.PlotMouseEvent) => {
+      this.ngZone.run(() => {
+        this.plotlyClick.emit(event);
+      });
+    });
+  }
+}
+</docs-code>
+
+The scenario of dispatching events outside of the Angular zone may also arise. It's important to remember that triggering change detection (for example, manually) may result in the creation/update of views outside of the Angular zone.
\ No newline at end of file
diff --git a/adev-es/src/content/best-practices/runtime-performance/zone-pollution.md b/adev-es/src/content/best-practices/runtime-performance/zone-pollution.md
index e232ec0..e488cc3 100644
--- a/adev-es/src/content/best-practices/runtime-performance/zone-pollution.md
+++ b/adev-es/src/content/best-practices/runtime-performance/zone-pollution.md
@@ -1,27 +1,27 @@
-# Resolving zone pollution
+# Resolviendo la contaminación de zone
 
-**Zone.js** is a signaling mechanism that Angular uses to detect when an application state might have changed. It captures asynchronous operations like `setTimeout`, network requests, and event listeners. Angular schedules change detection based on signals from Zone.js.
+**Zone.js** es un mecanismo de señalización que Angular usa para detectar cuándo el estado de una aplicación podría haber cambiado. Captura operaciones asíncronas como `setTimeout`, peticiones de red y escuchadores de eventos. Angular programa el change detection basándose en señales de Zone.js.
 
-In some cases scheduled [tasks](https://developer.mozilla.org/docs/Web/API/HTML_DOM_API/Microtask_guide#tasks) or [microtasks](https://developer.mozilla.org/docs/Web/API/HTML_DOM_API/Microtask_guide#microtasks) don’t make any changes in the data model, which makes running change detection unnecessary. Common examples are:
+En algunos casos, las [tareas](https://developer.mozilla.org/docs/Web/API/HTML_DOM_API/Microtask_guide#tasks) o [microtareas](https://developer.mozilla.org/docs/Web/API/HTML_DOM_API/Microtask_guide#microtasks) programadas no hacen ningún cambio en el modelo de datos, lo que hace que ejecutar change detection sea innecesario. Ejemplos comunes son:
 
-* `requestAnimationFrame`, `setTimeout` or `setInterval`
-* Task or microtask scheduling by third-party libraries
+* `requestAnimationFrame`, `setTimeout` o `setInterval`
+* Programación de tareas o microtareas por bibliotecas de terceros
 
-This section covers how to identify such conditions, and how to run code outside the Angular zone to avoid unnecessary change detection calls.
+Esta sección cubre cómo identificar tales condiciones, y cómo ejecutar código fuera de la zone de Angular para evitar llamadas innecesarias de change detection.
 
-## Identifying unnecessary change detection calls
+## Identificando llamadas innecesarias de change detection
 
-You can detect unnecessary change detection calls using Angular DevTools. Often they appear as consecutive bars in the profiler’s timeline with source `setTimeout`, `setInterval`, `requestAnimationFrame`, or an event handler. When you have limited calls within your application of these APIs, the change detection invocation is usually caused by a third-party library.
+Puedes detectar llamadas innecesarias de change detection usando Angular DevTools. A menudo aparecen como barras consecutivas en la línea de tiempo del perfilador con origen `setTimeout`, `setInterval`, `requestAnimationFrame`, o un manejador de eventos. Cuando tienes llamadas limitadas dentro de tu aplicación de estas APIs, la invocación de change detection usualmente es causada por una biblioteca de terceros.
 
-<img alt="Angular DevTools profiler preview showing Zone pollution" src="assets/images/best-practices/runtime-performance/zone-pollution.png">
+<img alt="Vista previa del perfilador de Angular DevTools mostrando contaminación de zone" src="assets/images/best-practices/runtime-performance/zone-pollution.png">
 
-In the image above, there is a series of change detection calls triggered by event handlers associated with an element. That’s a common challenge when using third-party, non-native Angular components, which do not alter the default behavior of `NgZone`.
+En la imagen anterior, hay una serie de llamadas de change detection disparadas por manejadores de eventos asociados con un elemento. Ese es un desafío común al usar componentes de terceros no nativos de Angular, que no alteran el comportamiento predeterminado de `NgZone`.
 
-## Run tasks outside `NgZone`
+## Ejecutar tareas fuera de `NgZone`
 
-In such cases, you can instruct Angular to avoid calling change detection for tasks scheduled by a given piece of code using [NgZone](/api/core/NgZone).
+En tales casos, puedes indicarle a Angular que evite llamar change detection para tareas programadas por un fragmento de código dado usando [NgZone](/api/core/NgZone).
 
-<docs-code header="Run outside of the Zone" language='ts' linenums>
+<docs-code header="Ejecutar fuera de la Zone" language='ts' linenums>
 import { Component, NgZone, OnInit } from '@angular/core';
 
 @Component(...)
@@ -34,11 +34,11 @@ class AppComponent implements OnInit {
 }
 </docs-code>
 
-The preceding snippet instructs Angular to call `setInterval` outside the Angular Zone and skip running change detection after `pollForUpdates` runs.
+El fragmento anterior le indica a Angular que llame `setInterval` fuera de la Zone de Angular y omita ejecutar change detection después de que `pollForUpdates` se ejecute.
 
-Third-party libraries commonly trigger unnecessary change detection cycles when their APIs are invoked within the Angular zone. This phenomenon particularly affects libraries that set up event listeners or initiate other tasks (such as timers, XHR requests, etc.). Avoid these extra cycles by calling library APIs outside the Angular zone:
+Las bibliotecas de terceros comúnmente disparan ciclos innecesarios de change detection cuando sus APIs son invocadas dentro de la zone de Angular. Este fenómeno afecta particularmente a bibliotecas que configuran escuchadores de eventos o inician otras tareas (como temporizadores, peticiones XHR, etc.). Evita estos ciclos adicionales llamando a las APIs de la biblioteca fuera de la zone de Angular:
 
-<docs-code header="Move the plot initialization outside of the Zone" language='ts' linenums>
+<docs-code header="Mover la inicialización del gráfico fuera de la Zone" language='ts' linenums>
 import { Component, NgZone, OnInit } from '@angular/core';
 import * as Plotly from 'plotly.js-dist-min';
 
@@ -54,13 +54,13 @@ class AppComponent implements OnInit {
 }
 </docs-code>
 
-Running `Plotly.newPlot('chart', data);` within `runOutsideAngular` instructs the framework that it shouldn’t run change detection after the execution of tasks scheduled by the initialization logic.
+Ejecutar `Plotly.newPlot('chart', data);` dentro de `runOutsideAngular` le indica al framework que no debe ejecutar change detection después de la ejecución de tareas programadas por la lógica de inicialización.
 
-For example, if `Plotly.newPlot('chart', data)` adds event listeners to a DOM element, Angular does not run change detection after the execution of their handlers.
+Por ejemplo, si `Plotly.newPlot('chart', data)` agrega escuchadores de eventos a un elemento DOM, Angular no ejecuta change detection después de la ejecución de sus manejadores.
 
-But sometimes, you may need to listen to events dispatched by third-party APIs. In such cases, it's important to remember that those event listeners will also execute outside of the Angular zone if the initialization logic was done there:
+Pero a veces, puedes necesitar escuchar eventos despachados por APIs de terceros. En tales casos, es importante recordar que esos escuchadores de eventos también se ejecutarán fuera de la zone de Angular si la lógica de inicialización se realizó allí:
 
-<docs-code header="Check whether the handler is called outside of the Zone" language='ts' linenums>
+<docs-code header="Verificar si el manejador es llamado fuera de la Zone" language='ts' linenums>
 import { Component, NgZone, OnInit, output } from '@angular/core';
 import * as Plotly from 'plotly.js-dist-min';
 
@@ -80,9 +80,9 @@ class AppComponent implements OnInit {
     const plotly = await Plotly.newPlot('chart', data);
 
     plotly.on('plotly_click', (event: Plotly.PlotMouseEvent) => {
-      // This handler will be called outside of the Angular zone because
-      // the initialization logic is also called outside of the zone. To check
-      // whether we're in the Angular zone, we can call the following:
+      // Este manejador será llamado fuera de la zone de Angular porque
+      // la lógica de inicialización también es llamada fuera de la zone. Para verificar
+      // si estamos en la zone de Angular, podemos llamar lo siguiente:
       console.log(NgZone.isInAngularZone());
       this.plotlyClick.emit(event);
     });
@@ -90,9 +90,9 @@ class AppComponent implements OnInit {
 }
 </docs-code>
 
-If you need to dispatch events to parent components and execute specific view update logic, you should consider re-entering the Angular zone to instruct the framework to run change detection or run change detection manually:
+Si necesitas despachar eventos a componentes padres y ejecutar lógica específica de actualización de vista, debes considerar volver a entrar a la zone de Angular para indicarle al framework que ejecute change detection o ejecutar change detection manualmente:
 
-<docs-code header="Re-enter the Angular zone when dispatching event" language='ts' linenums>
+<docs-code header="Volver a entrar a la zone de Angular al despachar evento" language='ts' linenums>
 import { Component, NgZone, OnInit, output } from '@angular/core';
 import * as Plotly from 'plotly.js-dist-min';
 
@@ -120,4 +120,4 @@ class AppComponent implements OnInit {
 }
 </docs-code>
 
-The scenario of dispatching events outside of the Angular zone may also arise. It's important to remember that triggering change detection (for example, manually) may result in the creation/update of views outside of the Angular zone.
\ No newline at end of file
+El escenario de despachar eventos fuera de la zone de Angular también puede surgir. Es importante recordar que disparar change detection (por ejemplo, manualmente) puede resultar en la creación/actualización de vistas fuera de la zone de Angular.
diff --git a/adev-es/src/content/best-practices/style-guide.en.md b/adev-es/src/content/best-practices/style-guide.en.md
new file mode 100644
index 0000000..63128d8
--- /dev/null
+++ b/adev-es/src/content/best-practices/style-guide.en.md
@@ -0,0 +1,320 @@
+# Angular coding style guide
+
+## Introduction
+
+This guide covers a range of style conventions for Angular application code. These recommendations
+are not required for Angular to work, but instead establish a set of coding practices that promote
+consistency across the Angular ecosystem. A consistent set of practices makes it easier to share
+code and move between projects.
+
+This guide does _not_ cover TypeScript or general coding practices unrelated to Angular. For
+TypeScript, check
+out [Google's TypeScript style guide](https://google.github.io/styleguide/tsguide.html).
+
+### When in doubt, prefer consistency
+
+Whenever you encounter a situation in which these rules contradict the style of a particular file,
+prioritize maintaining consistency within a file. Mixing different style conventions in a single
+file creates more confusion than diverging from the recommendations in this guide.
+
+## Naming
+
+### Separate words in file names with hyphens
+
+Separate words within a file name with hyphens (`-`). For example, a component named `UserProfile`
+has a file name `user-profile.ts`.
+
+### Use the same name for a file's tests with `.spec` at the end
+
+For unit tests, end file names with `.spec.ts`. For example, the unit test file for
+the `UserProfile` component has the file name `user-profile.spec.ts`.
+
+### Match file names to the TypeScript identifier within
+
+File names should generally describe the contents of the code in the file. When the file contains a
+TypeScript class, the file name should reflect that class name. For example, a file containing a
+component named `UserProfile` has the name `user-profile.ts`.
+
+If the file contains more than one primary namable identifier, choose a name that describes the
+common theme to the code within. If the code in a file does not fit within a common theme or feature
+area, consider breaking the code up into different files. Avoid overly generic file names
+like `helpers.ts`, `utils.ts`, or `common.ts`.
+
+### Use the same file name for a component's TypeScript, template, and styles
+
+Components typically consist of one TypeScript file, one template file, and one style file. These
+files should share the same name with different file extensions. For example, a `UserProfile`
+component can have the files `user-profile.ts`, `user-profile.html`, and `user-profile.css`.
+
+If a component has more than one style file, append the name with additional words that describe the
+styles specific to that file. For example, `UserProfile` might have style
+files `user-profile-settings.css` and `user-profile-subscription.css`.
+
+## Project structure
+
+### All the application's code goes in a directory named `src`
+
+All of your Angular UI code (TypeScript, HTML, and styles) should live inside a directory
+named `src`. Code that's not related to UI, such as configuration files or scripts, should live
+outside the `src` directory.
+
+This keeps the root application directory consistent between different Angular projects and creates
+a clear separation between UI code and other code in your project.
+
+### Bootstrap your application in a file named `main.ts` directly inside `src`
+
+The code to start up, or **bootstrap**, an Angular application should always live in a file
+named `main.ts`. This represents the primary entry point to the application.
+
+### Group closely related files together in the same directory
+
+Angular components consist of a TypeScript file and, optionally, a template and one or more style
+files. You should group these together in the same directory.
+
+Unit tests should live in the same directory as the code-under-test. Avoid collecting unrelated
+tests into a single `tests` directory.
+
+### Organize your project by feature areas
+
+Organize your project into subdirectories based on the features of your application or common themes
+to the code in those directories. For example, the project structure for a movie theater site,
+MovieReel, might look like this:
+
+```
+src/
+├─ movie-reel/
+│ ├─ show-times/
+│ │ ├─ film-calendar/
+│ │ ├─ film-details/
+│ ├─ reserve-tickets/
+│ │ ├─ payment-info/
+│ │ ├─ purchase-confirmation/
+```
+
+Avoid creating subdirectories based on the type of code that lives in those directories. For
+example, avoid creating directories like `components`, `directives`, and `services`.
+
+Avoid putting so many files into one directory that it becomes hard to read or navigate. As the
+number of files in a directory grows, consider splitting further into additional sub-directories.
+
+### One concept per file
+
+Prefer focusing source files on a single _concept_. For Angular classes specifically, this usually
+means one component, directive, or service per file. However, it's okay if a file contains more than
+one component or directive if your classes are relatively small and they tie together as part of a
+single concept.
+
+When in doubt, go with the approach that leads to smaller files.
+
+## Dependency injection
+
+### Prefer the `inject` function over constructor parameter injection
+
+Prefer using the `inject` function over injecting constructor parameters. The `inject` function works the same way as constructor parameter injection, but offers several style advantages:
+
+*   `inject` is generally more readable, especially when a class injects many dependencies.
+*   It's more syntactically straightforward to add comments to injected dependencies
+*   `inject` offers better type inference.
+*   When targeting ES2022+ with [`useDefineForClassFields`](https://www.typescriptlang.org/tsconfig/#useDefineForClassFields), you can avoid separating field declaration and initialization when fields read on injected dependencies.
+
+[You can refactor existing code to `inject` with an automatic tool](reference/migrations/inject-function).
+
+## Components and directives
+
+### Choosing component selectors
+
+See
+the [Components guide for details on choosing component selectors](guide/components/selectors#choosing-a-selector).
+
+### Naming component and directive members
+
+See the Components guide for details
+on [naming input properties](guide/components/inputs#choosing-input-names)
+and [naming output properties](guide/components/outputs#choosing-event-names).
+
+### Choosing directive selectors
+
+Directives should use the
+same [application-specific prefix](guide/components/selectors#selector-prefixes)
+as your components.
+
+When using an attribute selector for a directive, use a camelCase attribute name. For example, if
+your application is named "MovieReel" and you build a directive that adds a tooltip to an element,
+you might use the selector `[mrTooltip]`.
+
+### Group Angular-specific properties before methods
+
+Components and directives should group Angular-specific properties together, typically near the top
+of the class declaration. This includes injected dependencies, inputs, outputs, and queries. Define
+these and other properties before the class's methods.
+
+This practice makes it easier to find the class's template APIs and dependencies.
+
+### Keep components and directives focused on presentation
+
+Code inside your components and directives should generally relate to the UI shown on the page. For
+code that makes sense on its own, decoupled from the UI, prefer refactoring to other files. For
+example, you can factor form validation rules or data transformations into separate functions or
+classes.
+
+### Avoid overly complex logic in templates
+
+Angular templates are designed to
+accommodate [JavaScript-like expressions](guide/templates/expression-syntax).
+You should take advantage of these expressions to capture relatively straightforward logic directly
+in template expressions.
+
+When the code in a template gets too complex, though, refactor logic into the TypeScript code (typically with a [computed](guide/signals#computed-signals)).
+
+There's no one hard-and-fast rule that determines what constitutes "complex". Use your best
+judgement.
+
+### Use `protected` on class members that are only used by a component's template
+
+A component class's public members intrinsically define a public API that's accessible via
+dependency injection and [queries](guide/components/queries). Prefer `protected`
+access for any members that are meant to be read from the component's template.
+
+```ts
+@Component({
+  ...,
+  template: `<p>{{ fullName() }}</p>`,
+})
+export class UserProfile {
+  firstName = input();
+  lastName = input();
+
+// `fullName` is not part of the component's public API, but is used in the template.
+  protected fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
+}
+```
+
+### Use `readonly` for properties that shouldn't change
+
+Mark component and directive properties initialized by Angular as `readonly`. This includes
+properties initialized by `input`, `model`, `output`, and queries. The readonly access modifier
+ensures that the value set by Angular is not overwritten.
+
+```ts
+@Component({/* ... */})
+export class UserProfile {
+  readonly userId = input();
+  readonly userSaved = output();
+  readonly userName = model();
+}
+```
+
+For components and directives that use the decorator-based `@Input`, `@Output`, and query APIs, this
+advice applies to output properties and queries, but not input properties.
+
+```ts
+@Component({/* ... */})
+export class UserProfile {
+  @Output() readonly userSaved = new EventEmitter<void>();
+  @ViewChildren(PaymentMethod) readonly paymentMethods?: QueryList<PaymentMethod>;
+}
+```
+
+### Prefer `class` and `style` over `ngClass` and `ngStyle`
+
+Prefer `class` and `style` bindings over using the [`NgClass`](/api/common/NgClass) and [`NgStyle`](/api/common/NgStyle) directives.
+
+```html
+<!-- PREFER -->
+<div [class.admin]="isAdmin" [class.dense]="density === 'high'">
+<!-- OR -->
+<div [class]="{admin: isAdmin, dense: density === 'high'}">
+
+
+<!-- AVOID -->
+<div [ngClass]="{admin: isAdmin, dense: density === 'high'}">
+```
+
+Both `class` and `style` bindings use a more straightforward syntax that aligns closely with
+standard HTML attributes. This makes your templates easier to read and understand, especially for
+developers familiar with basic HTML.
+
+Additionally, the `NgClass` and `NgStyle` directives incur an additional performance cost compared
+to the built-in `class` and `style` binding syntax.
+
+For more details, refer to the [bindings guide](/guide/templates/binding#css-class-and-style-property-bindings)
+
+### Name event handlers for what they _do_, not for the triggering event
+
+Prefer naming event handlers for the action they perform rather than for the triggering event:
+
+```html
+<!-- PREFER -->
+<button (click)="saveUserData()">Save</button>
+
+<!-- AVOID -->
+<button (click)="handleClick()">Save</button>
+```
+
+Using meaningful names like this makes it easier to tell what an event does from reading the
+template.
+
+For keyboard events, you can use Angular's key event modifiers with specific handler names:
+
+```html
+<textarea (keydown.control.enter)="commitNotes()" (keydown.control.space)="showSuggestions()">
+```
+
+Sometimes, event handling logic is especially long or complex, making it impractical to declare a
+single well-named handler. In these cases, it's fine to fall back to a name like 'handleKeydown' and
+then delegate to more specific behaviors based on the event details:
+
+```ts
+
+@Component({/* ... */})
+class RichText {
+  handleKeydown(event: KeyboardEvent) {
+    if (event.ctrlKey) {
+      if (event.key === 'B') {
+        this.activateBold();
+      } else if (event.key === 'I') {
+        this.activateItalic();
+      }
+// ...
+    }
+  }
+}
+```
+
+### Keep lifecycle methods simple
+
+Avoid putting long or complex logic inside lifecycle hooks like `ngOnInit`. Instead, prefer creating
+well-named methods to contain that logic and then _call those methods_ in your lifecycle hooks.
+Lifecycle hook names describe _when_ they run, meaning that the code inside doesn't have a
+meaningful name that describes what the code inside is doing.
+
+```typescript
+// PREFER
+ngOnInit() {
+  this.startLogging();
+  this.runBackgroundTask();
+}
+
+// AVOID
+ngOnInit() {
+  this.logger.setMode('info');
+  this.logger.monitorErrors();
+  // ...and all the rest of the code that would be unrolled from these methods.
+}
+```
+
+### Use lifecycle hook interfaces
+
+Angular provides a TypeScript interface for each lifecycle method. When adding a lifecycle hook to
+your class, import and `implement` these interfaces to ensure that the methods are named correctly.
+
+```ts
+import {Component, OnInit} from '@angular/core';
+
+@Component({/* ... */})
+export class UserProfile implements OnInit {
+
+  // The `OnInit` interface ensures this method is named correctly.
+  ngOnInit() { /* ... */ }
+}
+```
diff --git a/adev-es/src/content/best-practices/style-guide.md b/adev-es/src/content/best-practices/style-guide.md
index 63128d8..19f59b8 100644
--- a/adev-es/src/content/best-practices/style-guide.md
+++ b/adev-es/src/content/best-practices/style-guide.md
@@ -1,84 +1,58 @@
-# Angular coding style guide
+# Guía de estilo de código Angular
 
-## Introduction
+## Introducción
 
-This guide covers a range of style conventions for Angular application code. These recommendations
-are not required for Angular to work, but instead establish a set of coding practices that promote
-consistency across the Angular ecosystem. A consistent set of practices makes it easier to share
-code and move between projects.
+Esta guía cubre un rango de convenciones de estilo para código de aplicaciones Angular. Estas recomendaciones no son requeridas para que Angular funcione, sino que establecen un conjunto de prácticas de codificación que promueven la consistencia en el ecosistema Angular. Un conjunto consistente de prácticas hace más fácil compartir código y moverse entre proyectos.
 
-This guide does _not_ cover TypeScript or general coding practices unrelated to Angular. For
-TypeScript, check
-out [Google's TypeScript style guide](https://google.github.io/styleguide/tsguide.html).
+Esta guía _no_ cubre TypeScript o prácticas generales de codificación no relacionadas con Angular. Para TypeScript, consulta la [guía de estilo TypeScript de Google](https://google.github.io/styleguide/tsguide.html).
 
-### When in doubt, prefer consistency
+### En caso de duda, prefiere la consistencia
 
-Whenever you encounter a situation in which these rules contradict the style of a particular file,
-prioritize maintaining consistency within a file. Mixing different style conventions in a single
-file creates more confusion than diverging from the recommendations in this guide.
+Siempre que te encuentres con una situación en la que estas reglas contradigan el estilo de un archivo particular, prioriza mantener la consistencia dentro de un archivo. Mezclar diferentes convenciones de estilo en un solo archivo crea más confusión que divergir de las recomendaciones en esta guía.
 
-## Naming
+## Nomenclatura
 
-### Separate words in file names with hyphens
+### Separa palabras en nombres de archivo con guiones
 
-Separate words within a file name with hyphens (`-`). For example, a component named `UserProfile`
-has a file name `user-profile.ts`.
+Separa palabras dentro de un nombre de archivo con guiones (`-`). Por ejemplo, un componente llamado `UserProfile` tiene un nombre de archivo `user-profile.ts`.
 
-### Use the same name for a file's tests with `.spec` at the end
+### Usa el mismo nombre para las pruebas de un archivo con `.spec` al final
 
-For unit tests, end file names with `.spec.ts`. For example, the unit test file for
-the `UserProfile` component has the file name `user-profile.spec.ts`.
+Para pruebas unitarias, termina los nombres de archivo con `.spec.ts`. Por ejemplo, el archivo de prueba unitaria para el componente `UserProfile` tiene el nombre de archivo `user-profile.spec.ts`.
 
-### Match file names to the TypeScript identifier within
+### Haz coincidir nombres de archivo con el identificador TypeScript dentro
 
-File names should generally describe the contents of the code in the file. When the file contains a
-TypeScript class, the file name should reflect that class name. For example, a file containing a
-component named `UserProfile` has the name `user-profile.ts`.
+Los nombres de archivo generalmente deben describir el contenido del código en el archivo. Cuando el archivo contiene una clase TypeScript, el nombre del archivo debe reflejar ese nombre de clase. Por ejemplo, un archivo que contiene un componente llamado `UserProfile` tiene el nombre `user-profile.ts`.
 
-If the file contains more than one primary namable identifier, choose a name that describes the
-common theme to the code within. If the code in a file does not fit within a common theme or feature
-area, consider breaking the code up into different files. Avoid overly generic file names
-like `helpers.ts`, `utils.ts`, or `common.ts`.
+Si el archivo contiene más de un identificador nombrable principal, elige un nombre que describa el tema común del código dentro. Si el código en un archivo no encaja dentro de un tema común o área de funcionalidad, considera dividir el código en diferentes archivos. Evita nombres de archivo demasiado genéricos como `helpers.ts`, `utils.ts`, o `common.ts`.
 
-### Use the same file name for a component's TypeScript, template, and styles
+### Usa el mismo nombre de archivo para el TypeScript, plantilla y estilos de un componente
 
-Components typically consist of one TypeScript file, one template file, and one style file. These
-files should share the same name with different file extensions. For example, a `UserProfile`
-component can have the files `user-profile.ts`, `user-profile.html`, and `user-profile.css`.
+Los componentes típicamente consisten en un archivo TypeScript, un archivo de plantilla y un archivo de estilo. Estos archivos deben compartir el mismo nombre con diferentes extensiones de archivo. Por ejemplo, un componente `UserProfile` puede tener los archivos `user-profile.ts`, `user-profile.html`, y `user-profile.css`.
 
-If a component has more than one style file, append the name with additional words that describe the
-styles specific to that file. For example, `UserProfile` might have style
-files `user-profile-settings.css` and `user-profile-subscription.css`.
+Si un componente tiene más de un archivo de estilo, agrega al nombre palabras adicionales que describan los estilos específicos de ese archivo. Por ejemplo, `UserProfile` podría tener archivos de estilo `user-profile-settings.css` y `user-profile-subscription.css`.
 
-## Project structure
+## Estructura del proyecto
 
-### All the application's code goes in a directory named `src`
+### Todo el código de la aplicación va en un directorio llamado `src`
 
-All of your Angular UI code (TypeScript, HTML, and styles) should live inside a directory
-named `src`. Code that's not related to UI, such as configuration files or scripts, should live
-outside the `src` directory.
+Todo tu código UI de Angular (TypeScript, HTML, y estilos) debe vivir dentro de un directorio llamado `src`. El código que no está relacionado con la UI, como archivos de configuración o scripts, debe vivir fuera del directorio `src`.
 
-This keeps the root application directory consistent between different Angular projects and creates
-a clear separation between UI code and other code in your project.
+Esto mantiene el directorio raíz de la aplicación consistente entre diferentes proyectos Angular y crea una separación clara entre el código UI y otro código en tu proyecto.
 
-### Bootstrap your application in a file named `main.ts` directly inside `src`
+### Inicia tu aplicación en un archivo llamado `main.ts` directamente dentro de `src`
 
-The code to start up, or **bootstrap**, an Angular application should always live in a file
-named `main.ts`. This represents the primary entry point to the application.
+El código para iniciar, o hacer **bootstrap**, de una aplicación Angular debe siempre vivir en un archivo llamado `main.ts`. Esto representa el punto de entrada principal a la aplicación.
 
-### Group closely related files together in the same directory
+### Agrupa archivos estrechamente relacionados juntos en el mismo directorio
 
-Angular components consist of a TypeScript file and, optionally, a template and one or more style
-files. You should group these together in the same directory.
+Los componentes de Angular consisten en un archivo TypeScript y, opcionalmente, una plantilla y uno o más archivos de estilo. Debes agrupar estos juntos en el mismo directorio.
 
-Unit tests should live in the same directory as the code-under-test. Avoid collecting unrelated
-tests into a single `tests` directory.
+Las pruebas unitarias deben vivir en el mismo directorio que el código bajo prueba. Evita recolectar pruebas no relacionadas en un solo directorio `tests`.
 
-### Organize your project by feature areas
+### Organiza tu proyecto por áreas de funcionalidad
 
-Organize your project into subdirectories based on the features of your application or common themes
-to the code in those directories. For example, the project structure for a movie theater site,
-MovieReel, might look like this:
+Organiza tu proyecto en subdirectorios basados en las características de tu aplicación o temas comunes al código en esos directorios. Por ejemplo, la estructura del proyecto para un sitio de cine, MovieReel, podría verse así:
 
 ```
 src/
@@ -91,89 +65,66 @@ src/
 │ │ ├─ purchase-confirmation/
 ```
 
-Avoid creating subdirectories based on the type of code that lives in those directories. For
-example, avoid creating directories like `components`, `directives`, and `services`.
+Evita crear subdirectorios basados en el tipo de código que vive en esos directorios. Por ejemplo, evita crear directorios como `components`, `directives`, y `services`.
 
-Avoid putting so many files into one directory that it becomes hard to read or navigate. As the
-number of files in a directory grows, consider splitting further into additional sub-directories.
+Evita poner tantos archivos en un directorio que se vuelva difícil de leer o navegar. A medida que el número de archivos en un directorio crece, considera dividir aún más en subdirectorios adicionales.
 
-### One concept per file
+### Un concepto por archivo
 
-Prefer focusing source files on a single _concept_. For Angular classes specifically, this usually
-means one component, directive, or service per file. However, it's okay if a file contains more than
-one component or directive if your classes are relatively small and they tie together as part of a
-single concept.
+Prefiere enfocar archivos fuente en un solo _concepto_. Para clases Angular específicamente, esto usualmente significa un componente, directiva, o servicio por archivo. Sin embargo, está bien si un archivo contiene más de un componente o directiva si tus clases son relativamente pequeñas y se vinculan juntas como parte de un solo concepto.
 
-When in doubt, go with the approach that leads to smaller files.
+En caso de duda, ve con el enfoque que lleve a archivos más pequeños.
 
-## Dependency injection
+## Inyección de dependencias
 
-### Prefer the `inject` function over constructor parameter injection
+### Prefiere la función `inject` sobre inyección de parámetros de constructor
 
-Prefer using the `inject` function over injecting constructor parameters. The `inject` function works the same way as constructor parameter injection, but offers several style advantages:
+Prefiere usar la función `inject` sobre inyectar parámetros de constructor. La función `inject` funciona de la misma manera que la inyección de parámetros de constructor, pero ofrece varias ventajas de estilo:
 
-*   `inject` is generally more readable, especially when a class injects many dependencies.
-*   It's more syntactically straightforward to add comments to injected dependencies
-*   `inject` offers better type inference.
-*   When targeting ES2022+ with [`useDefineForClassFields`](https://www.typescriptlang.org/tsconfig/#useDefineForClassFields), you can avoid separating field declaration and initialization when fields read on injected dependencies.
+*   `inject` es generalmente más legible, especialmente cuando una clase inyecta muchas dependencias.
+*   Es más directo sintácticamente agregar comentarios a dependencias inyectadas
+*   `inject` ofrece mejor inferencia de tipos.
+*   Al apuntar a ES2022+ con [`useDefineForClassFields`](https://www.typescriptlang.org/tsconfig/#useDefineForClassFields), puedes evitar separar la declaración e inicialización de campos cuando los campos leen dependencias inyectadas.
 
-[You can refactor existing code to `inject` with an automatic tool](reference/migrations/inject-function).
+[Puedes refactorizar código existente a `inject` con una herramienta automática](reference/migrations/inject-function).
 
-## Components and directives
+## Componentes y directivas
 
-### Choosing component selectors
+### Eligiendo selectores de componentes
 
-See
-the [Components guide for details on choosing component selectors](guide/components/selectors#choosing-a-selector).
+Consulta la [guía de Componentes para detalles sobre cómo elegir selectores de componentes](guide/components/selectors#choosing-a-selector).
 
-### Naming component and directive members
+### Nombrando miembros de componentes y directivas
 
-See the Components guide for details
-on [naming input properties](guide/components/inputs#choosing-input-names)
-and [naming output properties](guide/components/outputs#choosing-event-names).
+Consulta la guía de Componentes para detalles sobre [nombrar propiedades de entrada](guide/components/inputs#choosing-input-names) y [nombrar propiedades de salida](guide/components/outputs#choosing-event-names).
 
-### Choosing directive selectors
+### Eligiendo selectores de directivas
 
-Directives should use the
-same [application-specific prefix](guide/components/selectors#selector-prefixes)
-as your components.
+Las directivas deben usar el mismo [prefijo específico de aplicación](guide/components/selectors#selector-prefixes) que tus componentes.
 
-When using an attribute selector for a directive, use a camelCase attribute name. For example, if
-your application is named "MovieReel" and you build a directive that adds a tooltip to an element,
-you might use the selector `[mrTooltip]`.
+Al usar un selector de atributo para una directiva, usa un nombre de atributo camelCase. Por ejemplo, si tu aplicación se llama "MovieReel" y construyes una directiva que agrega un tooltip a un elemento, podrías usar el selector `[mrTooltip]`.
 
-### Group Angular-specific properties before methods
+### Agrupa propiedades específicas de Angular antes de los métodos
 
-Components and directives should group Angular-specific properties together, typically near the top
-of the class declaration. This includes injected dependencies, inputs, outputs, and queries. Define
-these and other properties before the class's methods.
+Los componentes y directivas deben agrupar las propiedades específicas de Angular juntas, típicamente cerca de la parte superior de la declaración de clase. Esto incluye dependencias inyectadas, entradas, salidas y consultas. Define estas y otras propiedades antes de los métodos de la clase.
 
-This practice makes it easier to find the class's template APIs and dependencies.
+Esta práctica hace más fácil encontrar las APIs de plantilla y dependencias de la clase.
 
-### Keep components and directives focused on presentation
+### Mantén componentes y directivas enfocados en la presentación
 
-Code inside your components and directives should generally relate to the UI shown on the page. For
-code that makes sense on its own, decoupled from the UI, prefer refactoring to other files. For
-example, you can factor form validation rules or data transformations into separate functions or
-classes.
+El código dentro de tus componentes y directivas generalmente debe relacionarse con la UI mostrada en la página. Para código que tiene sentido por sí solo, desacoplado de la UI, prefiere refactorizar a otros archivos. Por ejemplo, puedes factorizar reglas de validación de formularios o transformaciones de datos en funciones o clases separadas.
 
-### Avoid overly complex logic in templates
+### Evita lógica demasiado compleja en plantillas
 
-Angular templates are designed to
-accommodate [JavaScript-like expressions](guide/templates/expression-syntax).
-You should take advantage of these expressions to capture relatively straightforward logic directly
-in template expressions.
+Las plantillas de Angular están diseñadas para acomodar [expresiones similares a JavaScript](guide/templates/expression-syntax). Debes aprovechar estas expresiones para capturar lógica relativamente directa directamente en expresiones de plantilla.
 
-When the code in a template gets too complex, though, refactor logic into the TypeScript code (typically with a [computed](guide/signals#computed-signals)).
+Sin embargo, cuando el código en una plantilla se vuelve demasiado complejo, refactoriza la lógica al código TypeScript (típicamente con un [computed](guide/signals#computed-signals)).
 
-There's no one hard-and-fast rule that determines what constitutes "complex". Use your best
-judgement.
+No hay una regla única y rápida que determine qué constituye "complejo". Usa tu mejor juicio.
 
-### Use `protected` on class members that are only used by a component's template
+### Usa `protected` en miembros de clase que solo son usados por la plantilla de un componente
 
-A component class's public members intrinsically define a public API that's accessible via
-dependency injection and [queries](guide/components/queries). Prefer `protected`
-access for any members that are meant to be read from the component's template.
+Los miembros públicos de la clase de un componente intrínsecamente definen una API pública que es accesible vía inyección de dependencias y [consultas](guide/components/queries). Prefiere acceso `protected` para cualquier miembro que esté destinado a ser leído desde la plantilla del componente.
 
 ```ts
 @Component({
@@ -184,16 +135,14 @@ export class UserProfile {
   firstName = input();
   lastName = input();
 
-// `fullName` is not part of the component's public API, but is used in the template.
+// `fullName` no es parte de la API pública del componente, pero se usa en la plantilla.
   protected fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
 }
 ```
 
-### Use `readonly` for properties that shouldn't change
+### Usa `readonly` para propiedades que no deben cambiar
 
-Mark component and directive properties initialized by Angular as `readonly`. This includes
-properties initialized by `input`, `model`, `output`, and queries. The readonly access modifier
-ensures that the value set by Angular is not overwritten.
+Marca propiedades de componentes y directivas inicializadas por Angular como `readonly`. Esto incluye propiedades inicializadas por `input`, `model`, `output`, y consultas. El modificador de acceso readonly asegura que el valor establecido por Angular no sea sobrescrito.
 
 ```ts
 @Component({/* ... */})
@@ -204,8 +153,7 @@ export class UserProfile {
 }
 ```
 
-For components and directives that use the decorator-based `@Input`, `@Output`, and query APIs, this
-advice applies to output properties and queries, but not input properties.
+Para componentes y directivas que usan las APIs basadas en decoradores `@Input`, `@Output`, y consultas, este consejo aplica a propiedades de salida y consultas, pero no a propiedades de entrada.
 
 ```ts
 @Component({/* ... */})
@@ -215,54 +163,48 @@ export class UserProfile {
 }
 ```
 
-### Prefer `class` and `style` over `ngClass` and `ngStyle`
+### Prefiere `class` y `style` sobre `ngClass` y `ngStyle`
 
-Prefer `class` and `style` bindings over using the [`NgClass`](/api/common/NgClass) and [`NgStyle`](/api/common/NgStyle) directives.
+Prefiere enlaces `class` y `style` sobre usar las directivas [`NgClass`](/api/common/NgClass) y [`NgStyle`](/api/common/NgStyle).
 
 ```html
-<!-- PREFER -->
+<!-- PREFERIR -->
 <div [class.admin]="isAdmin" [class.dense]="density === 'high'">
-<!-- OR -->
+<!-- O -->
 <div [class]="{admin: isAdmin, dense: density === 'high'}">
 
 
-<!-- AVOID -->
+<!-- EVITAR -->
 <div [ngClass]="{admin: isAdmin, dense: density === 'high'}">
 ```
 
-Both `class` and `style` bindings use a more straightforward syntax that aligns closely with
-standard HTML attributes. This makes your templates easier to read and understand, especially for
-developers familiar with basic HTML.
+Tanto los enlaces `class` como `style` usan una sintaxis más directa que se alinea estrechamente con los atributos HTML estándar. Esto hace tus plantillas más fáciles de leer y entender, especialmente para desarrolladores familiarizados con HTML básico.
 
-Additionally, the `NgClass` and `NgStyle` directives incur an additional performance cost compared
-to the built-in `class` and `style` binding syntax.
+Adicionalmente, las directivas `NgClass` y `NgStyle` incurren en un costo de rendimiento adicional comparado con la sintaxis integrada de enlace `class` y `style`.
 
-For more details, refer to the [bindings guide](/guide/templates/binding#css-class-and-style-property-bindings)
+Para más detalles, consulta la [guía de enlaces](/guide/templates/binding#css-class-and-style-property-bindings)
 
-### Name event handlers for what they _do_, not for the triggering event
+### Nombra manejadores de eventos por lo que _hacen_, no por el evento disparador
 
-Prefer naming event handlers for the action they perform rather than for the triggering event:
+Prefiere nombrar manejadores de eventos por la acción que realizan en lugar de por el evento disparador:
 
 ```html
-<!-- PREFER -->
+<!-- PREFERIR -->
 <button (click)="saveUserData()">Save</button>
 
-<!-- AVOID -->
+<!-- EVITAR -->
 <button (click)="handleClick()">Save</button>
 ```
 
-Using meaningful names like this makes it easier to tell what an event does from reading the
-template.
+Usar nombres significativos como este hace más fácil saber qué hace un evento al leer la plantilla.
 
-For keyboard events, you can use Angular's key event modifiers with specific handler names:
+Para eventos de teclado, puedes usar los modificadores de eventos de tecla de Angular con nombres de manejadores específicos:
 
 ```html
 <textarea (keydown.control.enter)="commitNotes()" (keydown.control.space)="showSuggestions()">
 ```
 
-Sometimes, event handling logic is especially long or complex, making it impractical to declare a
-single well-named handler. In these cases, it's fine to fall back to a name like 'handleKeydown' and
-then delegate to more specific behaviors based on the event details:
+A veces, la lógica de manejo de eventos es especialmente larga o compleja, haciendo impráctico declarar un solo manejador bien nombrado. En estos casos, está bien volver a un nombre como 'handleKeydown' y luego delegar a comportamientos más específicos basados en los detalles del evento:
 
 ```ts
 
@@ -281,32 +223,28 @@ class RichText {
 }
 ```
 
-### Keep lifecycle methods simple
+### Mantén métodos de ciclo de vida simples
 
-Avoid putting long or complex logic inside lifecycle hooks like `ngOnInit`. Instead, prefer creating
-well-named methods to contain that logic and then _call those methods_ in your lifecycle hooks.
-Lifecycle hook names describe _when_ they run, meaning that the code inside doesn't have a
-meaningful name that describes what the code inside is doing.
+Evita poner lógica larga o compleja dentro de hooks de ciclo de vida como `ngOnInit`. En su lugar, prefiere crear métodos bien nombrados para contener esa lógica y luego _llamar esos métodos_ en tus hooks de ciclo de vida. Los nombres de hooks de ciclo de vida describen _cuándo_ se ejecutan, lo que significa que el código dentro no tiene un nombre significativo que describa qué está haciendo el código dentro.
 
 ```typescript
-// PREFER
+// PREFERIR
 ngOnInit() {
   this.startLogging();
   this.runBackgroundTask();
 }
 
-// AVOID
+// EVITAR
 ngOnInit() {
   this.logger.setMode('info');
   this.logger.monitorErrors();
-  // ...and all the rest of the code that would be unrolled from these methods.
+  // ...y todo el resto del código que se desplegaría de estos métodos.
 }
 ```
 
-### Use lifecycle hook interfaces
+### Usa interfaces de hooks de ciclo de vida
 
-Angular provides a TypeScript interface for each lifecycle method. When adding a lifecycle hook to
-your class, import and `implement` these interfaces to ensure that the methods are named correctly.
+Angular proporciona una interfaz TypeScript para cada método de ciclo de vida. Al agregar un hook de ciclo de vida a tu clase, importa e `implementa` estas interfaces para asegurar que los métodos estén nombrados correctamente.
 
 ```ts
 import {Component, OnInit} from '@angular/core';
@@ -314,7 +252,7 @@ import {Component, OnInit} from '@angular/core';
 @Component({/* ... */})
 export class UserProfile implements OnInit {
 
-  // The `OnInit` interface ensures this method is named correctly.
+  // La interfaz `OnInit` asegura que este método esté nombrado correctamente.
   ngOnInit() { /* ... */ }
 }
 ```
diff --git a/adev-es/src/content/best-practices/update.en.md b/adev-es/src/content/best-practices/update.en.md
new file mode 100644
index 0000000..3ce48ce
--- /dev/null
+++ b/adev-es/src/content/best-practices/update.en.md
@@ -0,0 +1,64 @@
+# Keeping your Angular projects up-to-date
+
+Just like Web and the entire web ecosystem, Angular is continuously improving.
+Angular balances continuous improvement with a strong focus on stability and making updates straightforward.
+Keeping your Angular application up-to-date enables you to take advantage of leading-edge new features, as well as optimizations and bug fixes.
+
+This document contains information and resources to help you keep your Angular applications and libraries up-to-date.
+
+For information about our versioning policy and practices —including support and deprecation practices, as well as the release schedule— see [Angular versioning and releases](reference/releases "Angular versioning and releases").
+
+HELPFUL: If you are currently using AngularJS, see [Upgrading from AngularJS](https://angular.io/guide/upgrade "Upgrading from Angular JS").
+*AngularJS* is the name for all v1.x versions of Angular.
+
+## Getting notified of new releases
+
+To be notified when new releases are available, follow [@angular](https://x.com/angular "@angular on X") on X (formerly Twitter) or subscribe to the [Angular blog](https://blog.angular.dev "Angular blog").
+
+## Learning about new features
+
+What's new? What's changed? We share the most important things you need to know on the Angular blog in [release announcements]( https://blog.angular.dev/ "Angular blog - release announcements").
+
+To review a complete list of changes, organized by version, see the [Angular change log](https://github.com/angular/angular/blob/main/CHANGELOG.md "Angular change log").
+
+## Checking your version of Angular
+
+To check your application's version of Angular use the `ng version` command from within your project directory.
+
+## Finding the current version of Angular
+
+The most recent stable released version of Angular appears [on npm](https://www.npmjs.com/package/@angular/core "Angular on npm") under "Version." For example, `16.2.4`.
+
+You can also find the most current version of Angular by using the CLI command [`ng update`](cli/update).
+By default, [`ng update`](cli/update)(without additional arguments) lists the updates that are available to you.
+
+## Updating your environment and apps
+
+To make updating uncomplicated, we provide complete instructions in the interactive [Angular Update Guide](update-guide).
+
+The Angular Update Guide provides customized update instructions, based on the current and target versions that you specify.
+It includes basic and advanced update paths, to match the complexity of your applications.
+It also includes troubleshooting information and any recommended manual changes to help you get the most out of the new release.
+
+For simple updates, the CLI command [`ng update`](cli/update) is all you need.
+Without additional arguments, [`ng update`](cli/update) lists the updates that are available to you and provides recommended steps to update your application to the most current version.
+
+[Angular Versioning and Releases](reference/releases#versioning "Angular Release Practices, Versioning") describes the level of change that you can expect based on a release's version number.
+It also describes supported update paths.
+
+## Resource summary
+
+* Release announcements:
+    [Angular blog - release announcements](https://blog.angular.dev/ "Angular blog announcements about recent releases")
+
+* Release details:
+    [Angular change log](https://github.com/angular/angular/blob/main/CHANGELOG.md "Angular change log")
+
+* Update instructions:
+    [Angular Update Guide](update-guide)
+
+* Update command reference:
+    [Angular CLI `ng update` command reference](cli/update)
+
+* Versioning, release, support, and deprecation practices:
+    [Angular versioning and releases](reference/releases "Angular versioning and releases")
diff --git a/adev-es/src/content/best-practices/update.md b/adev-es/src/content/best-practices/update.md
index 3ce48ce..86a53cc 100644
--- a/adev-es/src/content/best-practices/update.md
+++ b/adev-es/src/content/best-practices/update.md
@@ -1,64 +1,64 @@
-# Keeping your Angular projects up-to-date
+# Manteniendo tus proyectos Angular actualizados
 
-Just like Web and the entire web ecosystem, Angular is continuously improving.
-Angular balances continuous improvement with a strong focus on stability and making updates straightforward.
-Keeping your Angular application up-to-date enables you to take advantage of leading-edge new features, as well as optimizations and bug fixes.
+Al igual que la Web y todo el ecosistema web, Angular está mejorando continuamente.
+Angular equilibra la mejora continua con un fuerte enfoque en la estabilidad y en hacer las actualizaciones directas.
+Mantener tu aplicación Angular actualizada te permite aprovechar las nuevas funcionalidades de vanguardia, así como optimizaciones y correcciones de errores.
 
-This document contains information and resources to help you keep your Angular applications and libraries up-to-date.
+Este documento contiene información y recursos para ayudarte a mantener tus aplicaciones y bibliotecas Angular actualizadas.
 
-For information about our versioning policy and practices —including support and deprecation practices, as well as the release schedule— see [Angular versioning and releases](reference/releases "Angular versioning and releases").
+Para información sobre nuestra política y prácticas de versionado —incluyendo prácticas de soporte y deprecación, así como el calendario de lanzamientos— consulta [Versionado y lanzamientos de Angular](reference/releases "Versionado y lanzamientos de Angular").
 
-HELPFUL: If you are currently using AngularJS, see [Upgrading from AngularJS](https://angular.io/guide/upgrade "Upgrading from Angular JS").
-*AngularJS* is the name for all v1.x versions of Angular.
+ÚTIL: Si actualmente estás usando AngularJS, consulta [Actualizando desde AngularJS](https://angular.io/guide/upgrade "Actualizando desde Angular JS").
+*AngularJS* es el nombre para todas las versiones v1.x de Angular.
 
-## Getting notified of new releases
+## Recibiendo notificaciones de nuevos lanzamientos
 
-To be notified when new releases are available, follow [@angular](https://x.com/angular "@angular on X") on X (formerly Twitter) or subscribe to the [Angular blog](https://blog.angular.dev "Angular blog").
+Para recibir notificaciones cuando nuevos lanzamientos estén disponibles, sigue a [@angular](https://x.com/angular "@angular en X") en X (anteriormente Twitter) o suscríbete al [blog de Angular](https://blog.angular.dev "Blog de Angular").
 
-## Learning about new features
+## Aprendiendo sobre nuevas funcionalidades
 
-What's new? What's changed? We share the most important things you need to know on the Angular blog in [release announcements]( https://blog.angular.dev/ "Angular blog - release announcements").
+¿Qué hay de nuevo? ¿Qué ha cambiado? Compartimos las cosas más importantes que necesitas saber en el blog de Angular en [anuncios de lanzamiento]( https://blog.angular.dev/ "Blog de Angular - anuncios de lanzamiento").
 
-To review a complete list of changes, organized by version, see the [Angular change log](https://github.com/angular/angular/blob/main/CHANGELOG.md "Angular change log").
+Para revisar una lista completa de cambios, organizados por versión, consulta el [registro de cambios de Angular](https://github.com/angular/angular/blob/main/CHANGELOG.md "Registro de cambios de Angular").
 
-## Checking your version of Angular
+## Verificando tu versión de Angular
 
-To check your application's version of Angular use the `ng version` command from within your project directory.
+Para verificar la versión de Angular de tu aplicación usa el comando `ng version` desde dentro del directorio de tu proyecto.
 
-## Finding the current version of Angular
+## Encontrando la versión actual de Angular
 
-The most recent stable released version of Angular appears [on npm](https://www.npmjs.com/package/@angular/core "Angular on npm") under "Version." For example, `16.2.4`.
+La versión estable más reciente lanzada de Angular aparece [en npm](https://www.npmjs.com/package/@angular/core "Angular en npm") bajo "Version." Por ejemplo, `16.2.4`.
 
-You can also find the most current version of Angular by using the CLI command [`ng update`](cli/update).
-By default, [`ng update`](cli/update)(without additional arguments) lists the updates that are available to you.
+También puedes encontrar la versión más actual de Angular usando el comando CLI [`ng update`](cli/update).
+Por defecto, [`ng update`](cli/update)(sin argumentos adicionales) lista las actualizaciones que están disponibles para ti.
 
-## Updating your environment and apps
+## Actualizando tu entorno y aplicaciones
 
-To make updating uncomplicated, we provide complete instructions in the interactive [Angular Update Guide](update-guide).
+Para hacer la actualización sencilla, proporcionamos instrucciones completas en la [Guía de Actualización de Angular](update-guide) interactiva.
 
-The Angular Update Guide provides customized update instructions, based on the current and target versions that you specify.
-It includes basic and advanced update paths, to match the complexity of your applications.
-It also includes troubleshooting information and any recommended manual changes to help you get the most out of the new release.
+La Guía de Actualización de Angular proporciona instrucciones de actualización personalizadas, basadas en las versiones actuales y objetivo que especifiques.
+Incluye rutas de actualización básicas y avanzadas, para coincidir con la complejidad de tus aplicaciones.
+También incluye información de solución de problemas y cualquier cambio manual recomendado para ayudarte a aprovechar al máximo el nuevo lanzamiento.
 
-For simple updates, the CLI command [`ng update`](cli/update) is all you need.
-Without additional arguments, [`ng update`](cli/update) lists the updates that are available to you and provides recommended steps to update your application to the most current version.
+Para actualizaciones simples, el comando CLI [`ng update`](cli/update) es todo lo que necesitas.
+Sin argumentos adicionales, [`ng update`](cli/update) lista las actualizaciones que están disponibles para ti y proporciona pasos recomendados para actualizar tu aplicación a la versión más actual.
 
-[Angular Versioning and Releases](reference/releases#versioning "Angular Release Practices, Versioning") describes the level of change that you can expect based on a release's version number.
-It also describes supported update paths.
+[Versionado y Lanzamientos de Angular](reference/releases#versioning "Prácticas de Lanzamiento de Angular, Versionado") describe el nivel de cambio que puedes esperar basado en el número de versión de un lanzamiento.
+También describe las rutas de actualización soportadas.
 
-## Resource summary
+## Resumen de recursos
 
-* Release announcements:
-    [Angular blog - release announcements](https://blog.angular.dev/ "Angular blog announcements about recent releases")
+* Anuncios de lanzamiento:
+    [Blog de Angular - anuncios de lanzamiento](https://blog.angular.dev/ "Anuncios del blog de Angular sobre lanzamientos recientes")
 
-* Release details:
-    [Angular change log](https://github.com/angular/angular/blob/main/CHANGELOG.md "Angular change log")
+* Detalles de lanzamiento:
+    [Registro de cambios de Angular](https://github.com/angular/angular/blob/main/CHANGELOG.md "Registro de cambios de Angular")
 
-* Update instructions:
-    [Angular Update Guide](update-guide)
+* Instrucciones de actualización:
+    [Guía de Actualización de Angular](update-guide)
 
-* Update command reference:
-    [Angular CLI `ng update` command reference](cli/update)
+* Referencia del comando de actualización:
+    [Referencia del comando `ng update` de Angular CLI](cli/update)
 
-* Versioning, release, support, and deprecation practices:
-    [Angular versioning and releases](reference/releases "Angular versioning and releases")
+* Prácticas de versionado, lanzamiento, soporte y deprecación:
+    [Versionado y lanzamientos de Angular](reference/releases "Versionado y lanzamientos de Angular")