Node.js Translation to Spanish - (1621 words) (Part-72)
Repository
https://github.com/nodejs/i18n
Project Details
Node.js is an open-source, cross-platform JavaScript run-time environment that executes JavaScript code outside of a browser.
Node.js came into existence when the original developers of JavaScript extended it from something you could only run in the browser to something you could run on your machine as a standalone application.
In simple words, it's an open source execution environment for developing web applications, which is event-based, it uses the V8 engine to provide an execution environment that compiles and executes JavaScript at a higher speed. It is possible to run Node.js without any restriction on Windows, Linux and Mac OS X.
It should be noted that it is NOT a server language, this means that it executes code, so it could be understood as an interpreter.
Contribution Specifications
Node.js is currently being translated into 33 languages. I'm contributing to translate it into the Spanish language.
Translation Overview
In my previous contribution I worked on the Domain Module Postmortem folder, briefly based on the Domain folder that I translated on this occasion.
This module is currently deprecated. Some users agree that it doesn't matter if they are deprecated, domains are awesome if you use them right. Domains provide a way to handle multiple different IO operations as a single group and are useful for trapping errors thrown asynchronously. Using the global uncaughtException
and unhandledRejection
handlers don't solve the problem either. Only Domains can catch arbitrary errors like this.
Domains are useful for framework: they're a good way to separate 'user logic' from internal 'framework logic' for the purposes of failure handling and recovery.
Note that 'failure handling' is different from 'error handling'. A failure is a side effect to an Error. The user of a framework should be allowed to handle errors however they like, but sometimes you want the framework to decide how to handle the subsequent failure which resulted from that error.
For example, the framework itself might invoke a user-defined function which might branch off in unpredictable ways
and invoke various functions synchronously and/or asynchronously. In such a situation, if the user's code throws an Error, you may not want to just kill the whole server: you just want to shut down the single socket which was related to the specific action which caused the problem.
Basically, as a framework developer, domains offer you the ability to control the failure handling aspects related to code written by a third party.
I will add as an example of translation a section of this module as a warning/advice:
Warning: Don't Ignore Errors!
Domain error handlers are not a substitute for closing down your process when an error occurs.
By the very nature of how [throw][] works in JavaScript, there is almost never any way to safely "pick up where you left off", without leaking references, or creating some other sort of undefined brittle state.
The safest way to respond to a thrown error is to shut down the process. Of course, in a normal web server, you might have many connections open, and it is not reasonable to abruptly shut those down because an error was triggered by someone else.
The better approach is to send an error response to the request that triggered the error, while letting the others finish in their normal time, and stop listening for new requests in that worker.
In this way, domain usage goes hand-in-hand with the cluster module, since the master process can fork a new worker when a worker encounters an error. For Node.js programs that scale to multiple machines, the terminating proxy or service registry can take note of the failure, and react accordingly.
Advertencia: ¡No ignore los errores!
Los manejadores de errores de dominio no son un sustituto para el cierre de un proceso cuando se produce un error.
Por la naturaleza misma de cómo funciona [throw][] en JavaScript, casi nunca hay alguna forma segura de "regresar a donde se quedó", sin pérdidas de referencias o crear algún otro tipo de estado frágil e indefinido.
La manera más segura de responder a un error arrojado es cerrar el proceso. Por supuesto, en un servidor web normal, es posible que tenga muchas conexiones abiertas, y no es razonable cerrarlas abruptamente porque alguien más haya provocado un error.
La mejor solución es enviar una respuesta de error a la solicitud que produjo el error, dejando que las otras terminen en su tiempo habitual y deteniendo la escucha de nuevas solicitudes en ese worker.
De esta forma, el uso de domain se hace en conjunto al módulo clúster, ya que el proceso principal puede bifurcar un nuevo worker cuando un worker encuentre un error. Para los programas de Node.js que escalan en múltiples máquinas, el proxy final o servicio de registro pueden registrar la falla y reaccionar como corresponde.
Languages
This contribution was translated from English to Spanish.
Word Count
The number of words reflected in the title doesn't include words that didn't require a translation.
- In this contribution, I've translated 1621 words.
- I've translated a total of 97802 words so far*
*Considering non-translatable content (proper names, functions, codes, etc.)
To see my previous contributions in this project, check this!
Part 71
Part 70
Part 61
- Maintaining-V8.md (v6.x)
Part 56
Part 53
Part 52
Part 13
- Maintaining-V8.md (v10.x)
Proof of Authorship
This counter includes non-translatable words, so it is necessary to work on more content to extract an average of 1000 translatable words.
You can check My Crowdin Profile for verify my contribution in this project.
Greetings, @cremisi. Thanks for submitting your contribution!
Congratulations on this collaboration!
Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Chat with us on Discord
Thank you for your review, @alejohannes! Keep up the good work!
Hi @cremisi!
Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your post is eligible for our upvote, thanks to our collaboration with @utopian-io!
Feel free to join our @steem-ua Discord server
Hey, @cremisi!
Thanks for contributing on Utopian.
We’re already looking forward to your next contribution!
Get higher incentives and support Utopian.io!
Simply set @utopian.pay as a 5% (or higher) payout beneficiary on your contribution post (via SteemPlus or Steeditor).
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!