Node.js Translation to Spanish - (1621 words) (Part-72)

in #utopian-io5 years ago

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.

image.png

So far, we have managed to translate 72% of the project!

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.

kkkkkkkk.gif

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.

research.gif

If you're still not familiar about how domains are useful, you can see this Github gist.

I will add as an example of translation a section of this module as a warning/advice:

English:

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.

Spanish:

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!

Check.gif

Part 71

Part 70

From Part 62 to Part 69

Part 61

Parts 59 and 60

Parts 57 and 58

Part 56

Parts 54 and 55

Part 53

Part 52

From Part 41 to Part 51

From Part 14 to Part 40

Part 13

Parts 11 and 12.

From Part 7 to Part 10

From Part 1 to Part 6

Proof of Authorship

image.png

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.

Sort:  

Greetings, @cremisi. Thanks for submitting your contribution!

  • The presentation and contents of your post are good and satisfy the requirements for a complete evaluation of your contribution.
  • You did a precise use of the terminology and technical language involved in this translation.
  • The translated content fits coherently with the general meaning and use of the addressed strings.
  • You explained in a very clear way the contents of the file you collaborated to translate. Also, thanks for sharing an example of your work.
  • Nice personalization of your post!

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!