Merge pull request #22365 from newrelic/translations-aa2a9517

Updated translations -  (machine translation)

Author: jmiraNR

src/i18n/content/es/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts.mdx

@@ -119,23 +119,17 @@ Puedes crear roles en tres ámbitos diferentes, cada uno con propósitos diferen
 * **Roles de alcance de la organización**: estos roles se aplican para funciones de toda la organización, como gestionar el dominio de autenticación, crear cuentas, configurar los ajustes de la organización o gestionar cuadros de mando y equipos. Los roles estándar incluyen:
 
   * <DNT>**Organization manager**</DNT>:Licencias relacionadas con la configuración de la organización, incluida la adición de cuentas y el cambio de nombre de la organización y las cuentas. Esto también incluye tareas de observabilidad sensibles, como eliminar determinadas entidades.
-
-  * <DNT>**Authentication domain manager**</DNT>: Permisos relacionados con agregar y administrar usuarios, incluida la configuración del dominio de autenticación y la personalización de grupos y roles. Las opciones dentro de esto incluyen:
-
-    * <DNT>**Manage**</DNT>: Puede gestionar todos los aspectos del dominio de autenticación, incluida la configuración del dominio y la adición de usuarios.
-    * <DNT>**Read only**</DNT>: Puede ver el dominio de autenticación y la información del usuario.
-    * <DNT>**Add users**</DNT>: Puede ver información del usuario y agregar usuarios a la organización, pero carece de otras configuraciones de dominio de autenticación y capacidades de administración.
-    * <DNT>**Read users**</DNT>: Sólo puede ver la información del usuario.
-
+  * <DNT>**Authentication domain manager**</DNT>: Permissions related to adding and managing users, including configuring authentication domains and customizing groups and roles.
   * <DNT>**Billing**</DNT>: permite al usuario ver y administrar la facturación, el uso y la retención de datos. Para organizaciones con varias cuentas, la facturación se agrega en <DNT>**reporting account**</DNT> (generalmente la primera cuenta creada en una organización).
+  * <DNT>**Organization product admin**</DNT>: Permissions related to organization-scoped observability features like scorecard and team management. This is the organization-scoped equivalent to <strong>All product admin</strong>
 
-  * <DNT>**Organization product admin**</DNT>:Licencias relacionadas con características de observabilidad de ámbito organizacional como el cuadro de mando y la gestión de equipos. Este es el equivalente en el ámbito de la organización de <strong>Todos los administradores de productos</strong>.
+* <DNT>**Organization read only**</DNT>: Provides read-only access to the New Relic platform organization-scoped features.
 
 * **Roles de alcance de cuenta**: aplica estos roles para acceder a las características de la plataforma dentro de cuentas específicas, como configurar ajustes APM, gestionar alertas o ejecutar consultas. Éstos son los roles tradicionales con los que trabajan la mayoría de los usuarios. Los roles estándar incluyen:
 
   * <DNT>**All product admin**</DNT>:Incluye todas las licencias de la plataforma New Relic excepto la capacidad de gestionar configuraciones a nivel de organización, usuarios y facturación.
   * <DNT>**Standard user**</DNT>:Proporciona acceso a las características de nuestra plataforma pero carece de licencias para configurar dichas características y carece de licencias de gestión de usuarios y de nivel de organización.
-  * <DNT>**Read only**</DNT>:Proporciona acceso de solo lectura a la plataforma New Relic.
+  * <DNT>**Read only**</DNT>: Provides read-only access to the New Relic platform account-scoped features.
 
 * **Roles de ámbito de entidad**: estos roles se aplican para obtener acceso detallado a recursos específicos, como dashboards individuales, flotas o políticas de alertas. Esto permite un control preciso de licencias a nivel de recursos individuales. Puede crear roles personalizados con alcance de entidad según sus necesidades.
 

src/i18n/content/es/docs/apm/agents/nodejs-agent/getting-started/compatibility-requirements-nodejs-agent.mdx

@@ -282,10 +282,10 @@ Luego de la instalación, el agente se instrumenta automáticamente con nuestro
 | `@hapi/hapi`                      | 20.1.2                  | 21.4.4                   | 9.0.0                                  |
 | `@koa/router`                     | 12.0.1                  | 15.0.0                   | 3.2.0                                  |
 | `@langchain/core`                 | 0.1.17                  | 1.1.1                    | 11.13.0                                |
-| `@modelcontextprotocol/sdk`       | 1.13.0                  | 1.24.1                   | 13.2.0                                 |
+| `@modelcontextprotocol/sdk`       | 1.13.0                  | 1.24.2                   | 13.2.0                                 |
 | `@nestjs/cli`                     | 9.0.0                   | 11.0.14                  | 10.1.0                                 |
 | `@opensearch-project/opensearch`  | 2.1.0                   | 3.5.1                    | 12.10.0                                |
-| `@prisma/client`                  | 5.0.0                   | 7.0.1                    | 11.0.0                                 |
+| `@prisma/client`                  | 5.0.0                   | 7.1.0                    | 11.0.0                                 |
 | `@smithy/smithy-client`           | 2.0.0                   | 4.9.9                    | 11.0.0                                 |
 | `amqplib`                         | 0.5.0                   | 0.10.9                   | 2.0.0                                  |
 | `aws-sdk`                         | 2.2.48                  | 2.1692.0                 | 6.2.0                                  |

src/i18n/content/es/docs/apm/agents/ruby-agent/configuration/ruby-agent-configuration.mdx

@@ -5003,7 +5003,7 @@ Utilice esta configuración para alternar tipos de instrumentación durante el i
       </tbody>
     </table>
 
-    Esta configuración controla el comportamiento de la ejemplificación de transacciones cuando se muestrea un padre remoto y el indicador traza se establece en traceparent. Los valores disponibles son `default`, `always_on` y `always_off`.
+    Esta configuración controla el comportamiento de la ejemplificación de transacciones cuando se muestrea un padre remoto. Los valores disponibles son `default`, `always_on` y `always_off`.
   </Collapser>
 
   <Collapser id="distributed_tracing-sampler-remote_parent_not_sampled" title="distributed_tracing.sampler.remote_parent_not_sampled">
@@ -5041,7 +5041,7 @@ Utilice esta configuración para alternar tipos de instrumentación durante el i
       </tbody>
     </table>
 
-    Esta configuración controla el comportamiento de la ejemplificación de transacciones cuando no se muestrea un padre remoto y el indicador traza no está configurado en traceparent. Los valores disponibles son `default`, `always_on` y `always_off`.
+    Esta configuración controla el comportamiento de la ejemplificación de transacciones cuando no se muestrea un padre remoto. Los valores disponibles son `default`, `always_on` y `always_off`.
   </Collapser>
 </CollapserGroup>
 

src/i18n/content/es/docs/distributed-tracing/infinite-tracing-on-premise/bring-your-own-cache.mdx

@@ -20,21 +20,21 @@ The processor supports any Redis-compatible cache implementation. It has been te
 For production deployments, we recommend using cluster mode (sharded) to ensure high availability and scalability. To enable distributed caching, add the `distributed_cache` configuration to your `tail_sampling` processor section:
 
 ```yaml
-  tail_sampling:
-    distributed_cache:
-      connection:
-        address: redis://localhost:6379/0
-        password: 'local'
-      trace_window_expiration: 30s      # Default: how long to wait after last span before evaluating
-      in_flight_timeout: 120s           # Optional: defaults to trace_window_expiration if not set
-      traces_ttl: 3600s                 # Optional: default 1 hour
-      cache_ttl: 7200s                  # Optional: default 2 hours
-      suffix: "itc"                     # Redis key prefix
-      max_traces_per_batch: 500         # Default: traces processed per evaluation cycle
-      evaluation_interval: 1s           # Default: evaluation frequency
-      evaluation_workers: 4             # Default: number of parallel workers (defaults to CPU count)
-      data_compression:
-        format: lz4                     # Optional: compression format (none, snappy, zstd, lz4); lz4 recommended
+tail_sampling:
+  distributed_cache:
+    connection:
+      address: redis://localhost:6379/0
+      password: 'local'
+    trace_window_expiration: 30s      # Default: how long to wait after last span before evaluating
+    in_flight_timeout: 120s           # Optional: defaults to trace_window_expiration if not set
+    traces_ttl: 3600s                 # Optional: default 1 hour
+    cache_ttl: 7200s                  # Optional: default 2 hours
+    suffix: "itc"                     # Redis key prefix
+    max_traces_per_batch: 500         # Default: traces processed per evaluation cycle
+    evaluation_interval: 1s           # Default: evaluation frequency
+    evaluation_workers: 4             # Default: number of parallel workers (defaults to CPU count)
+    data_compression:
+      format: lz4                     # Optional: compression format (none, snappy, zstd, lz4); lz4 recommended
 ```
 
 <Callout variant="important">
@@ -44,16 +44,16 @@ For production deployments, we recommend using cluster mode (sharded) to ensure
 The `address` parameter must specify a valid Redis-compatible server address using the standard format:
 
 ```shell
-redis[s]://[[username][:password]@][host][:port][/db-number]
+[output] redis[s]://[[username][:password]@][host][:port][/db-number]
 ```
 
 Alternatively, you can embed credentials directly in the `address` parameter:
 
 ```yaml
-  tail_sampling:
-    distributed_cache:
-      connection:
-        address: redis://:yourpassword@localhost:6379/0
+tail_sampling:
+  distributed_cache:
+    connection:
+      address: redis://:yourpassword@localhost:6379/0
 ```
 
 The processor is implemented in Go and uses the [go-redis](https://github.com/redis/go-redis/tree/v9) client library.
@@ -120,8 +120,8 @@ Proper Redis instance sizing is critical for optimal performance. Use the config
 
 ### Memory estimation formula
 
-```shell
-  Total Memory = (Trace Data) + (Decision Caches) + (Overhead)
+```
+Total Memory = (Trace Data) + (Decision Caches) + (Overhead)
 ```
 
 #### 1. Trace data storage
@@ -142,13 +142,13 @@ Trace data is stored in Redis for the full `traces_ttl` period to support late-a
 
 **Example calculation**: At 10,000 spans/second with 1-hour `traces_ttl`:
 
-```shell
+```
 10,000 spans/sec × 3600 sec × 900 bytes = 32.4 GB
 ```
 
 **With lz4 compression** (we have observed 25% reduction):
 
-```shell
+```
 32.4 GB × 0.75 = 24.3 GB
 ```
 
@@ -175,7 +175,7 @@ When using `distributed_cache`, the decision caches are stored in Redis without
 
 **Example calculation**: 500 traces per batch (default) with 20 spans per trace on average:
 
-```shell
+```
 500 × 20 × 900 bytes = 9 MB per batch
 ```