Repository
https://github.com/nodejs/i18n
Project Details
Node.js, by definition, is an open-source, cross-platform JavaScript run-time environment that executes JavaScript code outside the browser. This means that now it is possible to execute a program written in JS outside a web browser such as Google Chrome, Safari, etc. This creates an extension to what the language can do, besides just creating interactive websites. With the help of the V8 JavaScript runtime engine, it can now take the code and convert it into a faster machine code, e. g., Node.js eliminates the waiting and continues to take care of the next task.
From my personal perspective, Node.js represents an advantage for the coders to write code, since it still has all the capabilities and functionalities JavaScript offers, but now in a more extended way. Also, thanks to all the time I have been contributing with this project, I have realized the huge amount of time and effort that the Node.js team has taken in order to make it as good as it is and also to improve it with every single upgrade.
You can take a look at their Crowdin project here.
Contribution Specifications
- Translation Overview
This is the 49th translation I made for the Node.js project, and on this contribution I continued translating the PULL-REQUESTS.MD folder. Such folder I define it as follows:
-- PULL-REQUESTS.MD: This folder's intention is to show the collaborators how to exactly create a pull request. It shows all the steps one has to follow in order to do so and also the steps taken for that request to be either accepted or denied. The whole tutorial is made out of 10 steps, and after that it advises how to properly review every single detail of the PR.
On this contribution I learned about two terms, one that I had no idea what it was, so I had to search for further information, and another one that I found very curious since the actual term sounds funny to say.
The first one is Continuos Integration (CI). It is defined as a development practice that requires developers or coders to integrate code into a shared repository plenty of times a day. Each check-in is continuously verified by an automated build, which allows teams to detect problems early. This practice has a great advantage, since the developer is constantly integrating, there is there is significantly less back-tracking to discover where things went wrong. Therefore you can spend more time building features.
There are 10 simple steps to follow in order to do a CI correctly:
- Developers check out code into their private workspaces
- When done, commit the changes to the repository
- The CI server monitors the repository and checks out changes when they occur
- The CI server builds the system and runs unit and integration tests
- The CI server releases deployable artifacts for testing
- The CI server assigns a build label to the version of the code it just built
- The CI server informs the team of the successful build
- If the build or tests fail, the CI server alerts the team
- The team fixes the issue at the earliest opportunity
- Continue to continually integrate and test throughout the project
Among the benefits of doing a CI we can find an increase on the visibility, enabling greater communication, catching issues early and nipping them in the bud, spending less time debugging, building a solid foundation and reducing integration problems, allowing you to deliver software quicker.
The next term is flaky test. (Sounds funny, right?). A flaky test is basically a test that sometimes passes and sometimes fails. Most of them are bok-choy acceptance tests, which tests the flow of the user through a site. Also, most of them are flaky because of how the test itself was written, and not due to an actual bug.
In order to know if you have encountered a flaky test, you just gotta find one that both fails and passes on the same commit in Jenkins. Now, there are two steps to follow in order to delete it, but since it requieres a long explanation, I will link the steps right here.
Examples of strings translated:
1. EN: When explicitly using the "Changes requested" component of the GitHub Approval
Workflow, show empathy.
SP: Cuando utilice explícitamente el componente de "Cambios solicitados" del Flujo de Trabajo
de GitHub, muestre empatía.
2. EN: Opinions on this vary, even among the members of the Technical Steering
Committee.
SP: Las opiniones sobre esto varían, incluso entre los miembros del Comité Directivo Técnico.
3. EN: It is not uncommon for contributors to suggest new features they feel would
make Node.js better.
SP: No es raro que los colaboradores sugieran nuevas funcionalidades que creen que podrían mejorar a Node.js.
References:
-- Thought Works. Continuous Integration (https://www.thoughtworks.com/continuous-integration)
-- OpenEDX. Flaky test process (https://openedx.atlassian.net/wiki/spaces/TE/pages/161427235/Flaky+Test+Process#FlakyTestProcess-Step1:Deletetheflakytest(s)inaPRbydoingthefollowing:)
- Languages
I translated from English to Spanish.
I have translated over 100,000 words utilizing the Crowdin platform and this has given me experience to always grant great quality translations.
- Word Count
I have translated 1,055 words. This contribution has been made between the dates Feb/20/2019, when I realized the translation, and March/02/2019, when I realized the corrections.
Previous translations on this project:
- Part 1
- Part 2
- Part 3
- Part 4
- Part 5
- Part 6
- Part 7
- Part 8
- Part 9
- Part 10
- Part 11
- Part 12
- Part 13
- Part 14
- Part 15
- Part 16
- Part 17
- Part 18
- Part 19
- Part 20
- Part 21
- Part 22
- Part 23
- Part 24
- Part 25
- Part 26
- Part 27
- Part 28
- Part 29
- Part 30
- Part 31
- Part 32
- Part 33
- Part 34
- Part 35
- Part 36
- Part 37
- Part 38
- Part 39
- Part 40
- Part 41
- Part 42
- Part 43
- Part 44
- Part 45
- Part 46
- Part 47
- Part 48
Proof of Authorship
Word Count
