Spanish translation: Add reviewed translations for One Paragraph Explainers

sections/errorhandling/apmproducts.spanish.md

@@ -1,9 +1,8 @@
-# Discover errors and downtime using APM products
+# Detectar errores y tiempos de inactividad a través de productos APM
 
+### Párrafo de explicación
 
-### One Paragraph Explainer
-
-Exception != Error. Traditional error handling assumes the existence of Exception but application errors might come in the form of slow code paths, API downtime, lack of computational resources and more. This is where APM products come in handy as they allow to detect a wide variety of ‘burried’ issues proactively with a minimal setup. Among the common features of APM products are for example alerting when the HTTP API returns errors, detect when the API response time drops below some threshold, detection of ‘code smells’, features to monitor server resources, operational intelligence dashboard with IT metrics and many other useful features. Most vendors offer a free plan.
+Exception != Error. La gestión tradicional de errores asume la existencia de Exception, pero los errores de la aplicación pueden manifestarse en forma de rutas de ejecución lentas, tiempos de inactividad de la API, falta de recursos computacionales y más. Es ahí donde los productos APM se tornan realmente útiles ya que permiten detectar una amplia variedad de problemas "enterrados", proactivamente y con una configuración mínima. Entre las características más comunes de productos APM están, por ejemplo, el alertar cuando se presentan errores HTTP API, detectar cuando el tiempo de respuesta de la API cae por debajo del umbral establecido, localizar ["code smells"](https://es.wikipedia.org/wiki/Hediondez_del_c%C3%B3digo), monitorizar recursos del servidor, proporcionar inteligencia operacional mediante paneles con métricas de IT y muchas otras funciones útiles. La mayoría de proveedores de este tipo de productos ofrecen algún plan gratuito.
 
 ### Wikipedia about APM
 

sections/errorhandling/asyncerrorhandling.spanish.md

@@ -1,8 +1,8 @@
-# Use Async-Await or promises for async error handling
+# Usar Async-Await o promises para capturar errores asíncronos
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-Callbacks don’t scale well since most programmers are not familiar with them. They force to check errors all over, deal with nasty code nesting and make it difficult to reason about the code flow. Promise libraries like BlueBird, async, and Q pack a standard code style using RETURN and THROW to control the program flow. Specifically, they support the favorite try-catch error handling style which allows freeing the main code path from dealing with errors in every function
+Los callbacks no escalan bien ya que muchos programadores no están familiarizados con ellos. Te obligan a estar pendiente de errores por todos lados y a lidiar con un anidamiento de código excesivo, lo cual dificulta la comprensión del flujo de código. Librerías prometedoras como BlueBird, async y Q empaquetan un estilo de código estándar utilizando RETURN y THROW para controlar el flujo del programa. Específicamente, soportan el estilo favorito de gestión de errores try-catch, liberando a la ruta principal de código de tratar con errores en cada función.
 
 ### Code Example – using promises to catch errors
 

sections/errorhandling/catchunhandledpromiserejection.spanish.md

@@ -1,10 +1,10 @@
-# Catch unhandled promise rejections
+# Capturar promises denegadas sin controlar
 
 <br/><br/>
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-Typically, most of modern Node.js/Express application code runs within promises – whether within the .then handler, a function callback or in a catch block. Surprisingly, unless a developer remembered to add a .catch clause, errors thrown at these places are not handled by the uncaughtException event-handler and disappear.  Recent versions of Node added a warning message when an unhandled rejection pops, though this might help to notice when things go wrong but it's obviously not a proper error handling method. The straightforward solution is to never forget adding .catch clauses within each promise chain call and redirect to a centralized error handler. However, building your error handling strategy only on developer’s discipline is somewhat fragile. Consequently, it’s highly recommended using a graceful fallback and subscribe to `process.on(‘unhandledRejection’, callback)` – this will ensure that any promise error, if not handled locally, will get its treatment.
+Normalmente, la mayor parte de código en aplicaciones Node.js/Express modernas funciona encerrado en "promises", ya sea en el interior de un .then, como en una función callback o en un bloque catch. Sorprendentemente, a menos que el desarrollador no olvide añadir una cláusula .catch, los errores que lanzados en estos sitios no son controlados por uncaughtException y desaparecen. Las últimas versiones de Node incorporan un mensaje de warning ante estas situaciones y, a pesar de la ayuda que esto supone cuando las cosas van mal, resulta evidente que no es el método adecuado para dar por resuelto el tema. La solución más sencilla es nunca olvidar cláusulas .catch en cada cadena de promises y redirigir el error al gestor de errores centralizado. Sin embargo, centrar tu estrategia de gestión de errores puramente en la disciplina del desarrollador es ciertamente frágil. Por lo tanto, se recomienda muchísimo utilizar una alternativa elegante: suscribirse a `process.on('unhandledRejection', callback)` – esto asegurará que cualquier error provinente de una promise, de no gestionarse localmente, siempre reciba su correcta gestión.
 
 <br/><br/>
 

sections/errorhandling/centralizedhandling.spanish.md

@@ -1,8 +1,8 @@
-# Handle errors centrally, through but not within a middleware
+# Gestiona los errores de manera central, "a través de" pero no "en" un middleware
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-Without one dedicated object for error handling, greater are the chances of important errors hiding under the radar due to improper handling. The error handler object is responsible for making the error visible, for example by writing to a well-formatted logger, sending events to some monitoring product or to an admin directly via email. A typical error handling flow might be: Some module throws an error -> API router catches the error -> it propagates the error to the middleware (e.g. Express, KOA) who is responsible for catching errors -> a centralized error handler is called -> the middleware is being told whether this error is an untrusted error (not operational) so it can restart the app gracefully. Note that it’s a common, yet wrong, practice to handle errors within Express middleware – doing so will not cover errors that are thrown in non-web interfaces
+Sin un objeto dedicado a la gestión de errores, son más las posibilidades de que errores importantes se oculten bajo el radar debido a una gestión inapropiada de los mismos. El objeto que gestiona el error es responsable de hacerlo visible, por ejemplo, mediante un logger bien formateado, enviando eventos hacia algún producto de monitorización o directamente a un administrador vía email. Un flujo típico de gestión de errores puede ser: Algún módulo tira un error –> el router de la API captura el error -> se propaga al middleware (ej. Express, KOA) responsable de atrapar errores -> se llama al objeto gestor de errores central -> se le indica al middleware si el error no es de fiar (no operacional) para que pueda reiniciar la aplicación de forma controlada. Nota que es una práctica común y, aun así mala práctica, el gestionar los errores directamente en el middleware de Express, pues de esa manera los errores lanzados en interfaces "no web" no quedan cubiertos.
 
 ### Code Example – a typical error flow
 

sections/errorhandling/documentingusingswagger.spanish.md

@@ -1,8 +1,8 @@
-# Document API errors using Swagger
+# Documentar errores API mediante Swagger
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-REST APIs return results using HTTP status codes, it’s absolutely required for the API user to be aware not only about the API schema but also about potential errors – the caller may then catch an error and tactfully handle it. For example, your API documentation might state in advance that HTTP status 409 is returned when the customer name already exists (assuming the API register new users) so the caller can correspondingly render the best UX for the given situation. Swagger is a standard that defines the schema of API documentation offering an eco-system of tools that allow creating documentation easily online, see print screens below
+Las APIs basadas en REST devuelven resultados utilizando códigos de estado HTTP. Es absolutamente necesario para el usuario de la API el ser consciente, no solo del esquema API, sino también de los errores potenciales. De ese modo puede atrapar el error y actuar en consecuencia. Por ejemplo, la documentación de tu API puede aclarar por adelantado que se devuelve el código HTTP 409 cuando el nombre del cliente ya existe (asumiendo que la API registre nuevos usuarios), por tanto la aplicación que consume la API puede proporcionar la mejor UX para la situación dada. Swagger es un estándar que define un esquema para generar documentación API, ofreciendo un ecosistema de herramientas que permiten crear fácilmente documentación online. Observa las siguientes capturas de pantalla.
 
 ### Blog Quote: "You have to tell your callers what errors can happen"
 

sections/errorhandling/failfast.spanish.md

@@ -1,8 +1,8 @@
-# Fail fast, validate arguments using a dedicated library
+# Falla rápido, valida los argumentos mediante una librería dedicada
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-We all know how checking arguments and failing fast is important to avoid hidden bugs (see anti-pattern code example below). If not, read about explicit programming and defensive programming. In reality, we tend to avoid it due to the annoyance of coding it (e.g. think of validating hierarchical  JSON object with fields like email and dates) – libraries like Joi and Validator turn this tedious task into a breeze.
+Todos sabemos que revisar argumentos y fallar cuanto antes es importante para evitar bugs ocultos (ver el código antipatrón de ejemplo a continuación). Si no, lee sobre programación explícita y defensiva. En realidad, tendemos a evitarlo por el fastidio que supone programarlo (por ej. piensa en validar un objeto JSON jerárquico con campos como email y fechas). Bibliotecas como Joi y Validator convierten esta tediosa tarea en calderilla.
 
 ### Wikipedia: Defensive Programming
 

sections/errorhandling/operationalvsprogrammererror.spanish.md

@@ -1,8 +1,8 @@
-# Distinguish operational vs programmer errors
+# Distinguir errores operacionales vs errores del programador
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-Distinguishing the following two error types will minimize your app downtime and helps avoid crazy bugs: Operational errors refer to situations where you understand what happened and the impact of it – for example, a query to some HTTP service failed due to connection problem. On the other hand, programmer errors refer to cases where you have no idea why and sometimes where an error came from – it might be some code that tried to read an undefined value or DB connection pool that leaks memory. Operational errors are relatively easy to handle – usually logging the error is enough. Things become hairy when a programmer error pops up, the application might be in an inconsistent state and there’s nothing better you can do than to restart gracefully
+Distinguir entre los siguientes dos tipos de error minimizará el downtime de la aplicación y ayudará a evitar comportamientos extraños: Los errores operacionales se refieren a situaciones en las que entendemos lo que ha pasado y su impacto, por ejemplo, una petición HTTP fallida por un problema de conexión. Por otro lado, los errores del programador se refieren a casos en los que no tienes ni idea de por qué ocurren (a veces ni de dónde vienen), puede tratarse de algún código que intenta leer un valor no definido o de una pool de conexión a base de datos que pierde memoria. Los errores operacionales son relativamente fáciles de gestionar –generalmente, con registrar el error es suficiente– pero las cosas se complican cuando salta un error del programador, ya que la aplicación puede quedar en un estado inconsistente y no hay nada mejor que puedas hacer que reiniciarla de forma controlada.
 
 ### Code Example – marking an error as operational (trusted)
 

sections/errorhandling/shuttingtheprocess.spanish.md

@@ -1,8 +1,8 @@
-# Exit the process gracefully when a stranger comes to town
+# Termina el proceso si llega un desconocido al pueblo
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-Somewhere within your code, an error handler object is responsible for deciding how to proceed when an error is thrown – if the error is trusted (i.e. operational error, see further explanation within best practice #3) then writing to log file might be enough. Things get hairy if the error is not familiar – this means that some component might be in a faulty state and all future requests are subject to failure. For example, assuming a singleton, stateful token issuer service that threw an exception and lost its state – from now it might behave unexpectedly and cause all requests to fail. Under this scenario, kill the process and use a ‘Restarter tool’ (like Forever, PM2, etc) to start over with a clean slate.
+En algún lugar del código, un objeto gestor de errores es responsable de decidir cómo se procede ante un error. Si ese error es confiable (ej. un error operacional, ver más información en mejores prácticas #3) con registrarlo en un log puede ser suficiente. Lo complicado viene cuando el error no es conocido, lo que implica que algún componente puede estar fallando y toda petición subsiguiente quedaría expuesta a fallar también. Por ejemplo, asumiendo una arquitectura singleton, un servicio proveedor de token con estado propio que lanza una excepción y pierde su estado podría, a partir de ese momento, comportarse de manera inesperada y provocar que todas las peticiones empiecen a fallar. Ante este escenario, termina el proceso y utiliza una "herramienta de reinicio" (como Forever, PM2, etc.) para empezar de cero limpiamente.
 
 ### Code example: deciding whether to crash
 

sections/errorhandling/testingerrorflows.spanish.md

@@ -1,8 +1,8 @@
-# Test error flows using your favorite test framework
+# Testear flujos de error mediante tu framework favorito de testing
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-Testing ‘happy’ paths is no better than testing failures. Good testing code coverage demands to test exceptional paths. Otherwise, there is no trust that exceptions are indeed handled correctly. Every unit testing framework, like [Mocha](https://mochajs.org/) & [Chai](http://chaijs.com/), supports exception testing (code examples below). If you find it tedious to test every inner function and exception you may settle with testing only REST API HTTP errors.
+Testear rutas de ejecución "felices" no es mejor que testear errores. Un buen coverage de código exige testear rutas de ejecución adversas. De lo contrario, no existe ninguna seguridad de que las excepciones se capturen y gestionen correctamente. Cada framework de testing unitario, como Mocha y Chai, admite testing de excepciones (códigos de ejemplo a continuación). Si te parece tedioso ir probando cada función y excepción internas, podrías quedarte solo con el testing de errores REST API HTTP.
 
 ### Code example: ensuring the right exception is thrown using Mocha & Chai
 

sections/errorhandling/usematurelogger.spanish.md

@@ -1,9 +1,8 @@
-# Use a mature logger to increase errors visibility
+# Utilizar un logger maduro para incrementar la visibilidad de errores
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-We all love console.log but obviously, a reputable and persistent logger like [Winston][winston], [Bunyan][bunyan] (highly popular) or [Pino][pino] (the new kid in town which is focused on performance) is mandatory for serious projects. A set of practices and tools will help to reason about errors much quicker – (1) log frequently using different levels (debug, info, error), (2) when logging, provide contextual information as JSON objects, see example below. (3) watch and filter logs using a log querying API (built-in in most loggers) or a log viewer software
-(4) Expose and curate log statement for the operation team using operational intelligence tools like Splunk
+A todos nos encanta console.log, pero evidentemente un logger persistente y con buena reputación como [Winston][winston], [Bunyan][bunyan] (tremendamente popular) o [Pino][pino] (la última novedad, centrado en el performance) es algo obligatorio para proyectos serios. Un conjunto de prácticas y herramientas nos ayudarán a tratar con errores mucho más rápido: (1) Utilizar diferentes niveles de log (debug, info, error). (2) Cuando creamos logs, proporcionar información contextual mediante objetos JSON, ver el ejemplo de abajo. (3) Mirar y filtrar logs a través de una API de consulta de logs (incorporado en la mayoría de loggers) o de un software visor de logs. (4) Exponer y curar las entradas de log para el equipo de operaciones utilizando herramientas de inteligencia operacional como Splunk.
 
 [winston]: https://www.npmjs.com/package/winston
 [bunyan]: https://www.npmjs.com/package/bunyan

sections/errorhandling/useonlythebuiltinerror.spanish.md

@@ -1,8 +1,8 @@
-# Use only the built-in Error object
+# Utiliza solo el objeto nativo de Error
 
-### One Paragraph Explainer
+### Párrafo de explicación
 
-The permissive nature of JS along with its variety code-flow options (e.g. EventEmitter, Callbacks, Promises, etc) pushes to great variance in how developers raise errors – some use strings, other define their own custom types. Using Node.js built-in Error object helps to keep uniformity within your code and with 3rd party libraries, it also preserves significant information like the StackTrace. When raising the exception, it’s usually a good practice to fill it with additional contextual properties like the error name and the associated HTTP error code. To achieve this uniformity and practices, consider extending the Error object with additional properties, see code example below
+La naturaleza permisiva de JS junto con sus variadas opciones de flujo de código (ej. EventEmitter, Callbacks, Promises, etc) provocan la existencia de una gran variedad de maneras de lanzar errores. Algunos utilizan strings, otros definen sus propios tipos personalizados. Utilizar el objeto nativo de Error presente en Node.js ayuda a mantener la uniformidad dentro de tu código y de librerías de terceros, así como a mantener información significativa como el StackTrace. Al lanzar la excepción, normalmente es buena práctica el agregar propiedades adicionales que aporten contexto, como el nombre del error y el código de error HTTP asociado. Para lograr esta uniformidad y estas prácticas, considera extender el objeto Error con propiedades adicionales, observa el ejemplo a continuación.
 
 ### Code Example – doing it right