Since Node.js is very easy to learn and it provides a lot of benefits for developers, there is a huge community of people involved with it, which is one of the reasons why this project is available to be translated into several languages (in crowdin, one of the best translation platforms in the web, this project is available to be translated into 33 different languages, Spanish being the one corresponding to this contribution), the ultimate goal in translating Node.js is to make it easier for developers from any country to start learning about this project in their own native language.
If you want to know more about Node.js feel free to visit its website.
- Translation Overview
This is my #31 contribution to Node.js, the project is right now 29% completed for the Spanish language, which means the team is advancing nicely with this project because in my previous contribution it was at 28%.
The folder I am translating right now is quite extensive, as you might remember from my previous contributions the name of this folder is CHANGELOG_V6.md, it is 57% completed and it has 42498 words in total, so there is still a long way to go before completing this folder.
The type of strings we can find in CHANGELOG_V6.md are always related to changes that should be applied to Node.js V6, as its name indicates, this folder is a registry of all the changes that were applied to this version, changes can be everything from fixing typos, improving internal elements, adding new information about deprecations & outdated data, among other similar modifications. This folder is divided into several sections, each of them corresponding to a different version. In this contribution, I translated strings from versions 6.9.2 and 6.9.3.
The section of the 6.9.3 version was a little bit different to what I am used to finding in this folder because a considerable number of the strings I encountered were about refactoring certain Node.js elements. In computing, refactoring means to change or restructuring something, with the goal of improving the way it is working, but without changing the way it must behave. This is usually done when developers figure out a better way to handle certain tests or because they discovered a bug in the code and then something like this happens in the office.
When beginning each section there is always a paragraph that indicates how many commits there are, and to which area are they related to, the following image shows an example of this text:
After that introductory paragraph, the notable changes are indicated, and finally, there is the list of commits which is always the most extensive part of each section.
These commits are written following a specific format: first there is a link to the GitHub commit, then there is the area related to this string, like for example “doc”, after this we have the short instruction for the change that needs to be applied, then the name of the person who proposed this change, and finally the link to the pull-request in GitHub. The following image provides a sample of the type of strings I always find in the Commit section:
Below I added a few examples of the translated strings:
use consistent checks for canceled timers
usar chequeos consistentes para temporizadores cancelados
forbid template literals in assert.throws
prohibir literales modelo en assert.throws
move source files from headers section
mover archivos fuente de sección de encabezados
When working on this contribution I was able to learn the following concept:
Realpath function: in computing, sometimes paths have symbolic links in their name, so let’s first remember what I said about symbolic links in a previous contribution:
… every time a file has a reference to another file or directory, it has a symbolic link. When an operating system finds one of these, it will automatically follow the path to the file or directory that is being referenced by the symbolic link. The difference between a symbolic link and a shortcut is that the symbolic link will make it look as if the referenced file is in the same folder as the symbolic link, which is something that doesn’t happen with shortcuts.
What a realpath function does is to remove all symbolic links, and it can either return “False” if the file doesn’t exist, or if everything goes well, it returns the resolved name.
If we see SpongeBob as a realpath function, he will be removing all the symbolic links he could, similar to the way he cleans his house:
In the previous contributions, I included the definition of these terms: deprecation, I/O - input/output, callback, asynchrony, POSIX, parsing, path, wildcard, wrapper function, stack trace, floating point value, error-first callbacks, transpilation tool, root certificate, little-endian, DNS rebinding, same-origin-policy, keep-alive behavior, stringification, arrow function, salt (cryptography), semver, lint, fixtures modules, newline, backporting, shell command, ES6 Classes , code refactoring, segfault, tarball, benchmark, type-check, deflate, char, aix, spawn, rehash, noop, rebasing, continuous integration, linkify, segfaults, IPC, libuv, toolchain, punycode, symlink, base64, interprocess communication (IPC), application binary interface (ABI), read–Eval–Print Loop (REPL), advanced Interactive eXecutive (AIX), GYP, Opaque binary blob (obb), symbolic link, destructuring, dotfiles and transport layer security (tls).
Source language: English
Translated language: Spanish
I have made several contributions in the past, and I published a series of articles in both languages. I am also part of the Utopian + DaVinci Spanish team.
- Word Count
Part 31: 1253 words
Total: 34258 words