[Phrase] Translation Updates - 2026-09-07

hugo/content/es/actions/private_actions/authorize_private_actions.md

@@ -0,0 +1,74 @@
+---
+description: Aprenda cómo Datadog autoriza Private Actions mediante Políticas de ejecución
+  y Conexiones.
+disable_toc: false
+further_reading:
+- link: actions/private_actions/
+  tag: Documentación
+  text: Descripción general de Private Actions
+- link: actions/private_actions/enroll_runner/
+  tag: Documentación
+  text: Inscripción y propiedad
+- link: actions/private_actions/set_up_agent_based/
+  tag: Documentación
+  text: Configurar un ejecutor de Private Actions
+- link: actions/private_actions/execution_policies/
+  tag: Documentación
+  text: Políticas de ejecución
+- link: actions/connections/
+  tag: Documentación
+  text: Conexiones
+title: Autorizar Private Actions
+---
+## Descripción general {#overview}
+
+Cuando sus flujos de trabajo y aplicaciones utilizan Private Actions, Datadog decide si la acción está permitida y, luego, su **runner de Private Actions** la ejecuta. Antes de que se envíe una tarea a un ejecutor, Datadog verifica si el usuario que realiza la solicitud tiene permiso para actuar en ese ejecutor. Si no está permitida, la tarea nunca se envía.
+
+Esta página explica cómo se toma esa decisión de autorización. Cubre los modelos que Datadog utiliza para permitir o denegar una acción, y qué modelo se aplica a su ejecutor.
+
+## Encuentre su modelo de autorización {#find-your-authorization-model}
+
+Un runner se autoriza mediante uno de dos modelos: [**Políticas de ejecución**](#execution-policies) o [**Conexiones**](#connections). El modelo está determinado por la propiedad del runner, establecida una vez cuando el runner se inscribe. Un runner determinado utiliza exactamente uno de estos modelos durante toda su vida útil; no puede combinar ambos en el mismo runner. Debido a que la propiedad se establece por runner, una sola flota basada en el Agent puede incluir runners sin propietario y con propietario, cada uno autorizado por su propio modelo.
+
+- **El runner en el Datadog Agent** depende de cómo se inscribió. Un runner de Agent sin propietario utiliza [Políticas de ejecución](#execution-policies); un runner de Agent con propietario utiliza [Conexiones](#connections).
+- **El runner independiente** siempre tiene propietario, por lo que siempre utiliza [Conexiones](#connections).
+
+Para saber cómo la inscripción establece la propiedad de un runner, consulte [Inscripción y propiedad][1].
+
+## Compare los dos modelos {#compare-the-two-models}
+
+|   | Políticas de ejecución | Conexiones |
+|---|---|---|
+| **Funciona con** | Runners solo en el Datadog Agent | Tanto runners independientes como runners en el Datadog Agent |
+| **Cómo se otorga el acceso** | Las Agent tags apuntan a uno o más conjuntos de runners, por lo que una política gestiona el acceso a través de una flota en lugar de una conexión separada por integración por runner | Una conexión almacena credenciales y las empareja con un solo runner |
+| **Credenciales** | Las políticas de ejecución no almacenan credenciales; el acceso se otorga mediante etiquetas de agente. Las acciones que requieren credenciales (por ejemplo, HTTP, GitLab y MongoDB) no son compatibles. | La conexión contiene las credenciales utilizadas para ejecutar la acción |
+| **Control** | Detallado: permite o deniega acciones específicas o conjuntos de acciones, además de alcances específicos de la integración, como los espacios de nombres de Kubernetes de destino para una acción de Kubernetes | Por runner: una conexión apunta a un runner específico |
+
+## Políticas de ejecución {#execution-policies}
+
+**Las políticas de ejecución** son un modelo de autorización para runners en el Datadog Agent. Cada política gestiona el acceso a través de uno o más conjuntos de runners a la vez. En lugar de una conexión independiente por integración por runner, usted utiliza **Agent tags** para definir los Agent de destino. Luego, les adjunta una regla de permitir o denegar.
+
+Las políticas de ejecución también proporcionan un control detallado. Una política puede permitir o denegar acciones específicas o conjuntos de acciones. También puede aplicar alcances específicos de la integración, como los espacios de nombres de Kubernetes de destino para una acción de Kubernetes. El acceso se otorga a través de Agent tags en lugar de credenciales almacenadas, por lo que las políticas de ejecución no almacenan credenciales y son utilizadas por runners sin propietario en el Agent.
+
+Para obtener más información sobre las políticas de ejecución y cómo configurarlas (objetivos, reglas, control de acceso y uso de políticas de ejecución en flujos de trabajo), consulte [Políticas de ejecución][2].
+
+## Conexiones {#connections}
+
+Las conexiones funcionan tanto para runners independientes como para runners en el Datadog Agent, y son el modelo utilizado por runners propios.
+
+Una conexión hace dos cosas:
+
+- **Hace referencia a las credenciales** necesarias para ejecutar una acción en su servicio. Las credenciales en sí (por ejemplo, un token de API o un nombre de usuario y contraseña) se almacenan localmente con el runner, en un archivo de credenciales en su servidor o contenedor; la conexión apunta a ellas.
+- **Empareja esas credenciales con un único runner.** Una conexión apunta a un runner, por lo que las credenciales solo son utilizadas por el runner que usted pretende.
+
+Para usar una conexión en un flujo de trabajo o aplicación, necesita el permiso adecuado para esa conexión. El acceso a una conexión puede restringirse para que solo las personas que la necesiten puedan usarla en sus flujos de trabajo y aplicaciones.
+
+Para obtener las instrucciones de configuración completas (creación, edición y restricción de conexiones, etiquetas de identificador de conexión y grupos de conexión), consulte [Conexiones][3].
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/actions/private_actions/enroll_runner/
+[2]: /es/actions/private_actions/execution_policies/
+[3]: /es/actions/connections/

hugo/content/es/actions/workflows/expressions/python.md

@@ -0,0 +1,121 @@
+---
+code_lang: python
+code_lang_weight: 20
+description: Capacidades y límites de las expresiones de Python en App Builder
+title: Expresiones de Python
+type: multi-code-lang
+---
+La acción de función de Python le permite escribir scripts de Python personalizados para transformaciones de datos, parseo y enriquecimiento de carga útil dentro de sus flujos de trabajo.
+
+## Entorno de Python{#python-environment}
+
+La acción de función de Python se ejecuta en un entorno de ejecución restringido con las siguientes características:
+
+{{< workflow-python-action-characteristics >}}
+
+## Estructura del script{#script-structure}
+
+Todos los scripts de Python deben definir una función `main` que acepte un parámetro `ctx` de tipo `Context`. Por ejemplo:
+
+```python
+from execution_context import Context
+
+def main(*, ctx: Context):
+  # Use ctx to access Trigger or Steps data
+  workflow_name = ctx["WorkflowName"]
+  return f"Running workflow {workflow_name!r}"
+```
+
+El objeto `ctx` proporciona acceso a todas las variables de contexto del flujo de trabajo, similar a la variable `$` en las expresiones de JavaScript. Utilice el acceso de estilo diccionario (por ejemplo, `ctx["Steps"]["Step_name"]["variable"]`) para hacer referencia a valores de pasos anteriores.
+
+## Agregar una acción de función de Python{#add-a-python-function-action}
+
+En el lienzo del flujo de trabajo: 
+1. Haga clic en {{< ui >}}\+{{< /ui >}} para agregar un paso al flujo de trabajo. 
+1. Busque `Python`. 
+1. Seleccione la acción de Python para agregarla a su flujo de trabajo.
+
+## Escribir scripts de Python con IA{#write-python-scripts-with-ai}
+
+Puede usar Bits AI para ayudar a escribir scripts de Python dentro de un paso del flujo de trabajo.
+
+Para escribir un script con Bits AI:
+
+1. Agregue un paso a su flujo de trabajo.
+1. En la sección {{< ui >}}Inputs{{< /ui >}}, haga clic en {{< ui >}}Write Code with AI{{< /ui >}}.
+1. Ingrese un prompt personalizado o seleccione uno de los prompts de ejemplo. 
+1. Opcionalmente, haga clic en {{< ui >}}Test script{{< /ui >}} para generar una vista previa del paso del flujo de trabajo. 
+1. Para guardar el script, haga clic en {{< ui >}}Accept changes{{< /ui >}}. Para continuar editando el script, haga clic en {{< ui >}}Reject changes{{< /ui >}}.
+1. Haga clic en {{< ui >}}X{{< /ui >}} para cerrar el cuadro de diálogo de IA. 
+1. Ingrese un {{< ui >}}Description{{< /ui >}}. 
+1. Haga clic en {{< ui >}}Save{{< /ui >}}.
+
+## Ejemplos de scripts {#script-examples}
+
+### Analizar y transformar datos JSON {#parse-and-transform-json-data}
+
+Este ejemplo analiza una cadena JSON de un paso anterior y extrae campos específicos.
+
+```python
+from execution_context import Context
+import json
+
+def main(*, ctx: Context):
+    # Get JSON string from previous step
+    json_string = ctx["Steps"]["Get_data"]["output"]
+
+    # Parse and transform
+    data = json.loads(json_string)
+    return {
+        "user_ids": [user["id"] for user in data["users"]],
+        "total_count": len(data["users"])
+    }
+```
+
+### Trabajar con fechas y marcas de tiempo {#work-with-dates-and-timestamps}
+
+Este ejemplo utiliza la biblioteca python-dateutil para realizar cálculos de fechas.
+
+```python
+from execution_context import Context
+from dateutil import parser, relativedelta
+from datetime import datetime
+
+def main(*, ctx: Context):
+    # Parse a date string
+    start_date = parser.parse(ctx["Trigger"]["date_string"])
+
+    # Calculate date 30 days in the future
+    future_date = start_date + relativedelta.relativedelta(days=30)
+
+    return {
+        "start": start_date.isoformat(),
+        "end": future_date.isoformat(),
+        "days_difference": 30
+    }
+```
+
+### Operaciones criptográficas {#cryptographic-operations}
+
+Este ejemplo utiliza la biblioteca rsa para cifrar un mensaje.
+
+```python
+from execution_context import Context
+import rsa
+import base64
+
+def main(*, ctx: Context):
+    # Get message from workflow context
+    message = ctx["Steps"]["Compose_message"]["text"]
+
+    # Generate RSA key pair
+    (public_key, private_key) = rsa.newkeys(512)
+
+    # Encrypt message
+    encrypted = rsa.encrypt(message.encode(), public_key)
+
+    return {
+        "encrypted_message": base64.b64encode(encrypted).decode(),
+        "public_key": public_key.save_pkcs1().decode()
+    }
+```