Merge branch 'master' of ssh://git.taler.net/tutorial-videos

2 files changed, 137 insertions, 0 deletions

diff --git a/translations/ES-Checking-the-merchant-API-configuration.mp4.txt b/translations/ES-Checking-the-merchant-API-configuration.mp4.txt
new file mode 100644
index 0000000..dca782d
--- /dev/null
+++ b/translations/ES-Checking-the-merchant-API-configuration.mp4.txt
@@ -0,0 +1,63 @@
+
+
+1)Hola y bienvenidos a este tutorial para aprender a como manejar la plataforma de Taler, así como el acceso a su API.
+
+2) Para poder seguir este videotutorial necesitarás tener acceso a un backend de vendedor (merchant) de GNU Taler, del estilo backend.demo.taler.net, pero sino cuentas con un servidor personal puedes usar el entorno demo de taler.net,
+que tiene la direccion https://backend.demo.taler.net.
+
+Para este tutorial no lo necesitarás quizás, pero para el resto de tutoriales, necesitarás tener instalada una Taler Wallet (extension de navegador o APP en tu teléfono móvil).
+
+Sino cuentas con una cartera Taler (wallet), existe otro tutorial disponible que te ayudará a conocer como instalar una, 
+bien en tu teléfono móvil (debe de ser un smartphone), o en tu navegador (como una extensión). 
+
+Para realizar este demostración de como acceder a los programas de la API, vamos a usar un software llamado "insomnia", 
+que nos permite visualizar las peticiones que realizamos contra la API, pero realmente puedes usar cualquier otro Software para el manejo de APIs,
+ o incluso implementar directamente los códigos API en tu lenguaje de programación preferido, como por ejemplo Python. 
+
+Para poder seguir este videotutorial en las mejores condiciones aconsejamos enormemente que uses el servidor de backend para demostraciones: backend.demo.taler.net.
+
+3) El servidor de merchant backende demo, está disponible en la dirección https://backend.demo.taler.net, con la  contraseña "sandbox". 
+De todas formas si deseas desplegar tu propia plataforma de backend, existe otro video-tutorial específicamente para realizar eso.
+
+4)  Primero que nada, empieza abriendo tu navegador y comprobando el puerto accede a la pagina de vendedor "merchant", conecta con tu RFC 8959 compliant access token, que como recordatorio es "sandbox" para el backend de demostración.
+
+Cuando veas la pagina principal, verás lo primero los pedidos que están a la espera de procesamiento. 
+Los pedidos están ocultos en el backend (ya que no son nuevos), pincha en "All" para verlos todos. 
+Encontrarás con seguridad muchos pedidos que están en proceso, que bien han sido cancelados, pagados o reembolsados. 
+Realmente es un histórico de todos los pedidos. Si estás haciendo uso de tu propio servidor con tu propia instalación del merchant backend de Taler, 
+seguramente no veas ningún pedido, pero no te preocupes, porque puedes continuar viendo el video-tutorial.
+
+5) Verás que todas las transacciones del servidor están realizadas en la divisa ficticia "KUDOS", y esta se utiliza exclusivamente de forma ficiticia en el servidor demo de Taler para realizar la demostración. 
+La divisa ficticia KUDOS, se encuentra tanto en la wallet, como en el backend del merchant. 
+Ten en cuenta los servidores de demostración no aceptan ningún otro tipo de divisa, más que kudos. 
+
+6) Ahora que ya tienes acceso a tu interfaz o backend de vendedor,  a través de tu navegador, vamos a comprobar que la API del servidor está funcionando igualmente, 
+para esto bien abre tu programa de manejo de API y apertura una plantilla que te permita ver las peticiones a la API.
+Prepara la primera llamada a la API (nosotros vamos a usar el programa Insomnia), y vamos a indicar la dirección del merchant igual a la de la demostración de taler que es https://backend.demo.taler.net.
+
+La meta de esta ruta, es listar todos los pedidos que han sido procesados por el servidor de backend de vendedor, 
+y si hay algun tipo de error, nos devolverá una lista vacía.
+
+Vamos a llevar a cabo una petición GET al endpoint de nuestro backend, /private/orders, pero antes de poder enviar esta petición concreta, necesitaremos incluir la información de autenticación como encabezado. 
+Tienes que especificar un tipo de autenticacion, en este caso "Bearer Token", que debemos rellenar con la cadena "secret-token:sandbox", para el caso del servidor demo. 
+Tendrás que enviar este mismo encabezado cada vez, para cada nueva cada petición, que quieras mandar la API con la ruta /private/*, y no lo olvides es un "Bearer Token".
+
+Si estáss usando un programa de manejo de peticiones API, quizás ahora es el mejor momento para guardarlo, y así poder realizar futuras peticiones al servidor. 
+Ahora ya puedes enviar esta petición a la API, bien sea el servidor merchant demo de Taler, o tu propio servidor merchant y si usas la clave de acceso correcta, 
+podrás ver todas la lista de transacciones que se han realizado en el servidor merchant. 
+Sino tuvieras ninguna transacción en tu servidor merchant, puedes al  menos comprobar que el código de respuesta es 200,y que no empieza  por 4 o 5, ya que esto seria sintomático de un error.
+
+Una de las ventaja de usar "Insomnia", es que puedes re-utilizar tu espacio de trabajo y transformarlo hacia código fuente del lenguaje de programación de tu elección. 
+Para ello, pincha en la flecha que apunta hacia abajo del botónn enviar, y pulsa sobre la opción "Generate client code", y así vas a ser capaz de generar código para cualquier lenguaje de programción como C, C sharp, Java, o Kotlin. En nuestro caso vamos a usar el lenguaje de programación Python. 
+El código generado es el código equivalente a la petición que hemos creado con el programa Insominia, junto con toda la información de esta petición contenida dentro de este código.
+
+6), Así que simplemente copia y pega el código generado, del lenguaje de programacion que hayas elegido,
+ en nuestro caso vamos a crear un archivo de texto plano para python. Copiamos el código generado dentro, guardamos el archivo, y luego simplemente lo ejecutamos. 
+Cuando lo ejecutemos podremos ver que todos los pedidos que veíamos en el programa "Insomnia", ahora los podemos ver por pantalla en modo texto. 
+
+Felicidades, has conseguido acceder a la API del servidor de vendedor (merchant) de Taler.
+
+Ahora ya podemos pasar al siguiente tutorial, para aprender a crear nuevas transacciones, comprobar los pagos, y manejar todas las plantillas re-usables.
+
+Muchas gracias por seguir este primer tutorial de inciación, nos vemos muy pronto para aprender de manera mas profunda el manejo de la API de Taler.
+
diff --git a/translations/ES-Web-Introduction+Merchant-API.mp4.txt b/translations/ES-Web-Introduction+Merchant-API.mp4.txt
new file mode 100644
index 0000000..cf15df1
--- /dev/null
+++ b/translations/ES-Web-Introduction+Merchant-API.mp4.txt
@@ -0,0 +1,74 @@
+1)
+
+Hola y bienvenidos a este video-tutorial, donde vamos a configurar los datos de configuración del Taler merchant.
+
+Si no estás familiarizado con el procesamiento de APIs, o programas para la gestión de peticiones API, o los lenguajes de programacion para realizar peticiones (requests),
+te recomendamos escanear el código QR que aparece en pantalla, o bien entra a través del enlace (link) mostrado en pantalla,
+y así podrás visualizar otro tutorial de como configurar tu entorno para realizar estas peticiones a la API.
+
+2)
+
+Para poder comprobar los datos de configuración del Taler merchant, simplemente realiza una llamada al "endpoint" de la API, y para ello vamos a realizar un petición GET,
+así en nuestro caso vamos a poner la dirección https://backend.demo.taler.net/config, pero por supuesto esta es la que usamos nosotros, pero tú quizás puedes poner la tuya propia (si dispones de tu propio servidor con el backend de merchant instalado).
+
+Una vez escrita la dirección anterior, simplemente pulsamos en "send" y deberíamos recibir una respuesta del servidor API, dándonos como resultado la configuración pública de tu backend.
+
+El primer elemento que debes comprobar antes de mirar el resto de datos de la configuración, es comprobar que estás comunicándote con el servicio de Taler correcto.
+Este está ubicado en el campo "name", y debes comprobar que su valor siempre es  "taler-merchant", y así de esta forma tendrás la completa seguridad de estar conectando
+con "merchant"  y no con "exchange", o cualquier otro componente del programa Taler.
+
+Así, ya que una en nuestro caso hemos comprobado que el valor es efectivamente "taler-merchant", podemos seguir comprobando el resto de los datos.
+
+El campo "currency", indica la divisa por defecto del servidor. y el campo "currencies" indica alguna información adicional sobre esta divisa concreta
+y entre estos campos podrás ver un montón de parámetros de configuracion relativos a la información mostrada,
+por ejemplo para que tu cliente muestre el formato de las cantidades de forma correcta.
+
+No vamos a entrar en los detalles de significado de cada parámetro en concreto, pero sí te animamos a que visites la documentación oficial de GNU Taler
+que siempre está actualizada para tu versión del Taler merchant.
+El enlace a la documentación está diponible en código QR que pudiste ver al comienzo del video, o bien visitando https://docs.taler.net
+
+Por último, en el último campo, podemos ver la versión del Taler merchant, como te habrás dado cuenta, este no es un número de versión normal,
+de hecho este sistema de versiones es llamado "libtool version system", y es importante que entiendas como funciona para que puedas desarrollar
+en nuestra plataforma de Taler, y así puedas asegurarte de que cada servicio que puedas encontrar en el sistema Taler, sea compatible con otro servicio.
+
+El sistema de versiones "libtool" es usado por todos los servicios Taler que puedas encontrar en la red. De hecho, si ya dispones de una cartera Taler (wallet) instalada en nuestro navegador o teléfono móvil, puedes ver en las configuraciones de tu cartera, que se hace uso de este mismo sistema de versiones "libtool"
+y podrás ver por ejemplo en mi caso, que las versiones "merchant" soportadas son las 5:0:1, que es la misma que tenemos en la API.
+
+Las versiones soportadas para el "exchange" por ejemplo son las versiones 17:0:0, y la Wallet Core Version es la 1:0:0, porfavor dejáme que te explique como funciona la herramienta del sistema de versiones "libtool".
+
+Así que vamos a coger el número de versión que vimos en los resultados de configuración devueltos por el servidor merchant 5:0:1, una cosa debemos entender antes que nada, es que el símbolo de los dos puntos ":", está ahí por una razón, es por que cada uno de estos tres números, tienen un significado diferente,
+así que empecemos por el primer número empezando por la izquierda.
+
+- Primer número: Este numero "5" ser refiere al número de versión de la API, que estamos usando, seríaa el equivalente al número principal de versión en un sistema tradicional de versiones.Así que en el momento se sube de versión por una gran mejora, o la API cambia significativamente, este número es incrementado en uno.
+
+- Segundo número: El siguiente número también comparte alguna similitud, con el sistema tradicional de versiones, este es número conocido como la "revisión", normalmente como programador, no debes de preocuparte mucho de este número de revisión, ya que son cambios muy pequeños en la implementación de la API, y que nunca debe afectar tu código fuente existente. Igual que en los sistemas de versiones normales, en el momento el número de versión se incremente en uno, el número de "revisión", volverá a valer cero.
+
+- Tercer número: El último número es mucho menos convencional, y es muy importante que entiendas muy bien su significado, porque no es un número que típicamente verás en un sistema de versiones tradicional. A este último número nos referimos con el nombre de edad "age", en la forma que se piensa referente a la "edad" en el sistema de versiones "libtool", significa o quiere decir, cuantas versiones anteriores podríamos ir hacia atrás, y al mismo tiempo continuar dando "soporte" a ellas.
+En este caso la edad tiene el valor de 1, que quiere decir, que solo podemos ir "una" versión hacia atrás y ofrecer compatibilidad, es decir, según vemos en el gráfico estosería la versión 4. Es decir que la compatibilidad la tendríamos para las versiones 4 y 5, independientemente del valor del número de "revisión".
+
+Así que si como programador, por ejemplo si escribieras código fuente, para la versión 4 de la API, en este momento concreto sí sería compatible.
+
+Supuestos:
+
+Supongamos que en el futuro la versión sube hacia la versión 6:0:1, tu código que era compatible con al versión 4, ya no será compatible, como puedes ver en el gráfico,
+esta versión solo soporta las versiones 5 y 6 como versión actual. Para poder soportar versión 4, en la versión 6, deberías tener en el campo "age" o edad, un valor de 2.
+Significando que tenemos la posibilidad de ir hacia atrás 2 versiones.
+
+Podriamos ir hacia atrás a la versión 5 y 4, y así tu código que fue realizado para la versión 4, sí seria compatible. De todas formas es aconsejable siempre referenciar laversión actual, porque la misión del campo "age" no es soportar todas las versiones de la API, ya que estas en algún punto pueden o van a  ser depreciadas, o incluso borradas en algún momento. Y el campo "age" irá cambiando acordemente para dejar de soportar la versión para tu código fuente de la API.
+
+Supongamos ahora que tenemos la version 5:0:1, así viendo el campo edad, vemos que soporta la versión 4, pero si hubiera una subida de versión solo borraría la compatibilidad con la versión 4, pero no cambiaría nada con la versión 5, y no cambiaría tampoco el destino (endpoints), entonces la subida de versión no cambiaria la versión actual, pero sí cambiaria la "revision", y la edad, que sería reseteada a 0.
+En este caso particular si suprimimos la compatibilidad para la versión 4, dejamos solo compatibilidad para versión 5, porque el valor de la edad es 0.
+
+Esto anteriormente explicado, es como afectaría esta subida de versión, a la compatibilidad. Es decir hemos hecho un pequeño cambio, que no afectaría si utilizas el código para la versión 5, sin embargo la revisión ha afectado al campo edad, y como consecuencia la versión 4, ya no estaría soportada como antes.
+
+Ahora ya conoces como funciona el sistema de versiones "libtool", y como se utiliza sobre todos los servicios de Taler. Así, si eres un programador y quieres desarrollar programas que se apoyen en la API del Taler Merchant, u otros servicios/componentes de Taler, ya sabes como --interpretar los números de versión, para saber si la versión de la API que estás usando, es compatible con tu código fuente o no.
+
+Muchas gracias por visualizar este vídeo, y aquí te dejamos de nuevo el código QR y el enlace de los recursos adicionales que puedes consultar para aprender más sobre otrostutoriales, y los recursos especiales que usamos para realizar estos videos.
+
+
+
+
+
+
+
+