Translate three unlisted pages into Spanish and update CLI Sync

docs/build-for-developers/build-compliant-apps.md

@@ -7,10 +7,10 @@ This section is for you if you are hoping to build or extend an existing
 application that can connect to OpenFn. We follow modern web-standard JSON API
 guidelines.
 
-For your application to a be data provider (or "source") for OpenFn
+For your application to be a data provider (or "source") for OpenFn
 integrations, we highly recommend that you create a "notifications service"
 (sometimes called a "webhooks service" or "event-based push API"). This is
-preferable to using a REST api for two reasons: (1) A notifications service will
+preferable to using a REST API for two reasons: (1) A notifications service will
 give your clients the ability to set up real-time integrations, and (2) a
 notifications service is more efficient for both your servers and OpenFn—instead
 of having requests be made and handled every X seconds, your servers and
@@ -35,19 +35,19 @@ curl -X POST \
 ```
 
 OpenFn will respond with a 200 and an empty JSON object in the event of a
-successful post. 400s mean that the user's external URL is wrong, and 500s means
+successful post. 400s mean that the user's external URL is wrong, and 500s mean
 that there is an application error on OpenFn. While 500s are rare, they could be
 due to invalid JSON in your POST body.
 
 If you cannot notify an external URL when some event takes place, you can still
 integrate with OpenFn if you have a JSON-based REST API. OpenFn users can make
 HTTP GET requests to your application and perform additional actions based on
-your response. You should allow either basic or token authentication and
-response to a valid GET with JSON. There is no specific format for your
-response, as users can parse it any way they'd like, extracting relevant data
-and then performing other actions—like loading it into a destination system—with
-that data. See [language-http](https://www.github.com/openfn/language-http) for
-details on how users make these generic HTTP requests.
+your response. You should allow either basic or token authentication and respond
+to a valid GET with JSON. There is no specific format for your response, as
+users can parse it any way they'd like, extracting relevant data and then
+performing other actions—like loading it into a destination system—with that
+data. See [language-http](/adaptors/http) for details on how users make these
+generic HTTP requests.
 
 ### Payload sizing
 
@@ -61,15 +61,14 @@ keep your payloads well below that limit.
 To make it easy for users to connect to your application, it's highly
 recommended that you create a language-package with your required authentication
 and a set of simple, allowable actions nicely abstracted into "helper
-functions". See [language-dhis2](https://www.github.com/openfn/language-dhis2)
-for an example of a language-package which creates a simpler interface for a
-traditional JSON-based REST api. Adaptors are written in Javascript and execute
-in Node. You can convert OpenFn's JSON into XML, or any other format before
-sending it to your application and you may make use of any node modules you'd
-like. See
-[language-postgresql](https://www.github.com/openfn/language-postgresql) for an
-example of an adaptor that connects directly to PostgreSQL databases using a
-popular NPM module called "pg".
+functions". See [language-dhis2](/adaptors/dhis2) for an example of a
+language-package which creates a simpler interface for a traditional JSON-based
+REST API. Adaptors are written in JavaScript and execute in Node. You can
+convert OpenFn's JSON into XML, or any other format before sending it to your
+application and you may make use of any node modules you'd like. See
+[language-postgresql](/adaptors/postgresql) for an example of an adaptor that
+connects directly to PostgreSQL databases using a popular NPM module called
+"pg".
 
 To receive data from OpenFn's generic `language-http` adaptor, your application
 must allow either basic, token, or digest authenticated POST, PUT, or GET

docs/build-for-developers/cli-sync.md

@@ -69,7 +69,7 @@ Whether using the CLI or GitHub Sync, a Project has the following structure:
     ├── my-workflow
     │   ├── my-workflow.yaml
     │   ├── my-step.js
-├──.openfn
+├── .openfn
 ```
 
 Briefly, these files are:
@@ -81,11 +81,11 @@ Briefly, these files are:
 - `workflows` contains one sub folder per workflow, and "expands" a workflow to
   the file system for convenient editing.
 - The `.projects` folder contains a complete YAML representation of each
-  Project. This is rarely used by humans
+  Project. This is rarely used by humans.
 - The `.openfn` folder contains metadata used by the CLI. It is not used by
   humans and should not be checked-in to git.
 
-::: note
+:::note
 
 For users well-versed in the OpenFn portability specification, this folder
 structure represents a project _spec_. The `.projects` folder contains project
@@ -102,12 +102,12 @@ workflows a little easier.
 
 A workflow can be defined as a single yaml file - you'll see that if you hit
 "View workflow as YAML" in the app, or if you look at the project state files in
-`.projects. But for convenience, the workflow can also be "checked out" or
+`.projects`. But for convenience, the workflow can also be "checked out" or
 expanded so that each step has its job code (its expression) written to a .js
 file.
 
-You edit these expanded workflow files as much as you like, and changes will be
-tracked when you push/deploy back to the app.
+You can edit these expanded workflow files as much as you like, and changes will
+be tracked when you push/deploy back to the app.
 
 You can only check out one project at a time. This is actually great for working
 with git, because you can checkout two projects on different branches and

docs/design/overview.md

@@ -43,7 +43,7 @@ Good user stories will capture 3 parts:
 2. _What_ - what do they hope to achieve via the solution?
 3. _Why_ - why is this desire important? What are the business implications?
 
-If you capture these 3 elements, user stories can b ean effective way of
+If you capture these 3 elements, user stories can be an effective way of
 detailing integration requirements and starting discussions at your organization
 about which requirements are priority.
 
@@ -57,16 +57,16 @@ about which requirements are priority.
   from the district clinic electronic medical record system with the national
   DHIS2 health information system, so that I can securely and automatically
   report on health outcomes for key indicators in my district.
-- **Kobo Toolbox - MSSQL Database:** As a M&E manager, I want to monitor Kobo
-  Toolbox survey responses in a central database in real-time, so that I can
+- **KoboToolbox - MSSQL Database:** As a M&E manager, I want to monitor
+  KoboToolbox survey responses in a central database in real-time, so that I can
   better understand data collection activities and program performance across my
   research partner sites.
 
 ## 2. Diagram the business process
 
 Once the user stories have been identified, start to document the functional
 processes that are in place (or will need to be implemented) in order to achieve
-the desired requirments. These might be automated or human/manually-driven
+the desired requirements. These might be automated or human/manually-driven
 processes. This is the precursor step to mapping out the data flow (which
 details the technical steps for how connections will be made and data exchanged
 between systems). Again, process mapping is _business analysis_–not a technical
@@ -76,16 +76,13 @@ For example, if you want to exchange information between your organization and
 another... how might this exchange work from a functional point of view? _What_
 information will be exchanged? With _whom_ (between which systems or users)?
 _When_ will the information be exchanged? And what are the human or automation
-steps that should facilitate and trigger this exchange? These business process
-questions are discussed in more detail on the
-[So, what is an integration?](/documentation/tutorials/tutorial/) page.
+steps that should facilitate and trigger this exchange?
 
-:::tip
+:::tip Capture the current & desired process
 
-Capture the current & desired process Document _current and desired_ business
-processes in order to determine how information should be exchanged between your
-organization/system/users and others, and to ensure alignment of expectations
-and assumptions across partners.
+Document _current and desired_ business processes in order to determine how
+information should be exchanged between your organization/system/users and
+others, and to ensure alignment of expectations and assumptions across partners.
 
 :::
 
@@ -125,10 +122,10 @@ Once the business processes are documented, start to document the specific data
 elements to be exchanged. This exercise requires a lot of specificity to detail
 the individual "fields" or "attributes" to be exchanged.
 
-The output of this exerice is a `Data Element Mapping Specification`, which will
-serve as (1) documentation of the specific data elements agreed to be exchanges,
-as well as (2) a guide for how to translate meaning between partners and systems
-(e.g., `client` in one system might mean `patient` in another).
+The output of this exercise is a `Data Element Mapping Specification`, which
+will serve as (1) documentation of the specific data elements agreed to be
+exchanged, as well as (2) a guide for how to translate meaning between partners
+and systems (e.g., `client` in one system might mean `patient` in another).
 
 If your organization already has a data management or sharing agreement, this
 might be the perfect starting point for identifying the specific data points to
@@ -197,5 +194,5 @@ solution, as well as memorialize the business decisions and agreements made by
 implementing partners.
 
 Share this documentation with any technical implementation team, or check out
-the [Build](/documentation/build/workflows) documentation section to learn how
-to implement these design specifications using OpenFn.
+the [Build](/build/workflows.md) documentation section to learn how to implement
+these design specifications using OpenFn.

i18n/es/docusaurus-plugin-content-docs/current/build-for-developers/build-compliant-apps.md

@@ -0,0 +1,80 @@
+---
+title: Desarrollar aplicaciones conectadas
+sidebar_label: Crear API compatibles
+translation_source_hash: e0d8e1d398d235e8cb533a3eb6d4f55280ad62d5
+translation_review_status: machine
+---
+
+Esta sección es para ti si quieres crear una aplicación que se pueda conectar a
+OpenFn, o ampliar una que ya tengas. Seguimos las pautas modernas de los
+estándares web para las API JSON.
+
+Para que tu aplicación sea un proveedor de datos (o "origen") para las
+integraciones de OpenFn, te recomendamos mucho que crees un "servicio de
+notificaciones" (a veces llamado "servicio de webhooks" o "API push basada en
+eventos"). Es mejor que usar una API REST por dos motivos: (1) un servicio de
+notificaciones permite a tus clientes configurar integraciones en tiempo real, y
+(2) un servicio de notificaciones es más eficiente tanto para tus servidores
+como para OpenFn: en lugar de hacer y atender solicitudes cada X segundos, tus
+servidores y los de OpenFn solo trabajan cuando hay datos nuevos.
+
+Para que tu aplicación sea un consumidor (o "destino") de OpenFn, debes tener
+una API REST estándar basada en JSON o crear un language-package que cumpla las
+especificaciones de tu API.
+
+## Enviar datos a OpenFn {#sending-data-to-openfn}
+
+Para enviar datos a OpenFn, tu aplicación debe poder hacer un POST por HTTPS a
+una URL externa, con un objeto JSON válido como cuerpo. Mira este ejemplo con
+cURL:
+
+```sh
+curl -X POST \
+  -H "Content-Type: application/json" \
+  -H "Cache-Control: no-cache" \
+  -d '{"foo":"bar", "baz":"qux"}' \
+  "https://app.openfn.org/i/some-secret-inbox-uuid"
+```
+
+Si el POST se completa correctamente, OpenFn responde con un 200 y un objeto
+JSON vacío. Un error 400 significa que la URL externa del usuario es incorrecta,
+y un 500 significa que hay un error de la aplicación en OpenFn. Los errores 500
+son poco frecuentes, pero pueden deberse a un JSON no válido en el cuerpo del
+POST.
+
+Si no puedes notificar a una URL externa cuando ocurre un evento, puedes
+integrarte con OpenFn de todos modos si tienes una API REST basada en JSON. Los
+usuarios de OpenFn pueden hacer solicitudes HTTP GET a tu aplicación y realizar
+otras acciones según tu respuesta. Deberías permitir la autenticación básica o
+por token, y responder con JSON a un GET válido. La respuesta no tiene que
+seguir ningún formato concreto, porque los usuarios pueden procesarla como
+quieran: extraer los datos que les interesan y luego hacer otras acciones con
+ellos, como cargarlos en un sistema de destino. Consulta
+[language-http](/adaptors/http) para ver cómo hacen los usuarios estas
+solicitudes HTTP genéricas.
+
+### Tamaño del payload {#payload-sizing}
+
+Si usas la plataforma y no piensas contratar un plan empresarial, tendrás que
+tener en cuenta el tamaño de los datos que envías en cada payload. El `state` de
+un run suele estar limitado a `10MB`, así que deberías mantener tus payloads muy
+por debajo de ese límite.
+
+## Recibir datos de OpenFn {#receiving-data-from-openfn}
+
+Para que los usuarios puedan conectarse fácilmente a tu aplicación, te
+recomendamos mucho que crees un language-package con la autenticación que
+necesitas y un conjunto de acciones sencillas y permitidas, bien abstraídas en
+"funciones auxiliares". Consulta [language-dhis2](/adaptors/dhis2) para ver un
+ejemplo de language-package que crea una interfaz más sencilla para una API REST
+tradicional basada en JSON. Los adaptors se escriben en JavaScript y se ejecutan
+en Node. Puedes convertir el JSON de OpenFn a XML, o a cualquier otro formato,
+antes de enviarlo a tu aplicación, y puedes usar los módulos de Node que
+quieras. Consulta [language-postgresql](/adaptors/postgresql) para ver un
+ejemplo de adaptor que se conecta directamente a bases de datos PostgreSQL con
+un módulo de NPM muy conocido llamado "pg".
+
+Para recibir datos del adaptor genérico `language-http` de OpenFn, tu aplicación
+debe permitir solicitudes POST, PUT o GET con autenticación básica, por token o
+digest. (Aunque no es recomendable crear una API que exija solicitudes GET para
+crear o actualizar datos.)

i18n/es/docusaurus-plugin-content-docs/current/build-for-developers/build-with-api.md

@@ -0,0 +1,13 @@
+---
+id: build-with-api
+title: Crear proyectos con la API de OpenFn
+sidebar_label: Crear con la API
+slug: /build-with-api
+translation_source_hash: 4578f2253ce460b1b667107c61855e2079036646
+translation_review_status: machine
+---
+
+OpenFn te permite configurar proyectos con solicitudes HTTP enviadas a la API
+REST. Consulta el
+[repositorio de OpenFn/Lightning en GitHub](https://openfn.github.io/lightning/provisioning.html)
+para ver la documentación detallada para desarrolladores.