Node.js is a global platform and so this site has many translations. The translation of the site into languages other than English is handled by Crowdin translators.
- Request to join the Nodejs-Website in Crowdin
- Select the language you want to translate
- Start translating
If you have any questions or feedbacks on current translations, you can start a discussion by choosing the "New Topic" and your language from the right dropdown, or a conversation by adding your translators.
Go on /i18n/config.json
and add the new language to the locales
array.
Fill the language object with the following fields:
{
"code": "fr",
"localName": "Français",
"name": "French",
"langDir": "ltr",
"dateFormat": "DD.MM.YYYY",
"hrefLang": "fr",
"enabled": true
}
Field Name | Description | Examples |
---|---|---|
code |
The language code. It must be the same as the folder name | fr |
localName |
The language name in its own language (it's use in language selector) | Français |
name |
The language name in English | French |
langDir |
The direction of the language. ltr for left to right, rtl for right to left |
ltr |
dateFormat |
The date format. It must be a valid moment.js format | DD.MM.YYYY |
hrefLang |
The language code in ISO 639-1 format | fr |
enabled |
If the language is enabled or not | true |
Please also add the new locale file to the locales folder /i18n/locales
and import it in the /i18n/locales/index.mjs
file.
If you're making a new Component and adding Translation Keys for your Component, they should follow these guidelines:
- Only add the new translation keys on the
i18n/locales/en.json
file. Crowdin will handle on syncing the files and letting translators know there are new keys to be translated - The translation keys should have the prefix as the canonical path of your Component. If your Component is
components/Common/MyComponent
the prefix key should becomponents.common.myComponent
- The Translation Key suffix should be easy to undersand and semantic. For example, if the key is about "the text of a button that when interacted it copies content to the clipboard", the suffix should probably be
copyButton.title
. The final translation key would becomponents.common.myComponent.copyButton.title
- Translation Keys should be in Camel Case only.
- The values of each Translation Key should follow the ICU Message Syntax
- The Translation Key suffix should be easy to undersand and semantic. For example, if the key is about "the text of a button that when interacted it copies content to the clipboard", the suffix should probably be
- All new Translation keys should be added at the bottom of the
i18n/locales/en.json
file. Since this makes it easier for Translators to notice that there are new Translation keys to be translated.
Translation Keys should not be translated during Unit Testing. If your Component uses, for example FormattedMessage
, you should provide the <IntlProvider>
surrounding your testing-library
render logic, or you can create a wrapper for your test. Note that you should not import the English messages to your Unit Test as:
- Unit Testing should test a Component functionality.
- Unit Tests should not rely on text, titles, or string bags, as these texts will change arbitrarily and make the test suite fail.
- In this case, you should test your component by aria-text, or other
aria-*
attributes or even by class names or other artifacts.
- In this case, you should test your component by aria-text, or other
- If you want to test how different languages and text appear within a Component, Visual Regression Testing is recommended.