Once we've landed #57 and #77, we'll have translated content flowing into this repo in the form of markdown files sorted into subdirectories by node version and language. To make this translated content easier to consume by projects like nodejs/website-redesign, we should export a node module that is easy to install and easy to use. The name could be something like nodejs-i18n.

The existing electron-i18n module can be used as a reference:

• Has no runtime dependencies
• Exports a single JSON object
• Exports pre-parsed GitHub-style HTML with hubdown, a collection of remark plugins.

The module exports an object with the following structure:

i18n.docs[language][path]

For example:

i18n.docs['en-US']['/docs/api/browser-window']

Each document object looks something like this:

{ 
  locale: 'en-US',
  slug: 'browser-window',
  category: 'api',
  href: '/docs/api/browser-window',
  githubUrl: 'https://github.com/electron/electron/tree/master/docs/api/browser-window.md',
  crowdinFileId: '68',
  title: 'BrowserWindow',
  description: 'Create and control browser windows.',
  html: '...' 
}

I would like to join the group and contribute to i18n initiative

I'm currently member of the nodejs-pt i10n group, and I would like to be part of this WG.

Purpose

Our group needs to be brought up to speed on what's been discussed with @Andrulko and our WG members who were present at our meeting with Crowdin on 02/26/18.

WG members: Please provide any thoughts or feedback you have here concerning using Crowdin and we'll get things rolling. 🙌

Meeting Recap

i18n WG members in attendance

• @zeke
• @vanessayuenn
• @sotayamashita
• @obensource

@Andrulko gave us a setup overview, and demoed Crowdin's repo integration & l10n features.

Crowdin Integration Features

• Syncing a repo with Crowdin via their Github integration process
• Syncing and managing l10n project resources directly with the Crowdin CLI interface

Crowdin l10n Features

• In-context translation for web apps
  • Translation can be done by selecting an app's text in the UI, and live translating it directly.
• Proofreading & voting of translations
  • Translations can be proofread and/or voted on by project peers before being approved.

Electron use cases we can learn from

• API translation: The Electron i18n repo pulls markdown files in from their API docs for translation.
• A crowdin.yaml file is maintained to map source files to their translation location.
• Crowdin uses a yaml file as well to map to the source and target resources it needs to manage. In theory you should be able to manage that with git, however at this point in time it must be generated and added within a Crowdin project itself.
• l10n project resources live under a directory labeled by their associated ISO standard locale code.

Upstream vs. downstream bottleneck

One important discussion we began to consider was the tradeoff between having to accept translations as PRs for verification–or hopefully keeping that responsibility effectively downstream by requesting that translators maintain at least one peer verification for every translation to be published. This should be painless in Crowdin by ensuring translators follow their 'edit & proofreading' model.

The security tradeoff in the codebase comes with a trust that the translations will be fine, and we can simply merge them as they come in–bypassing the GH PR process entirely.

I come from China and I'm currently member of the electron/i18n team,request to join nodejs i18n team

I discovered the initiative thanks to Electron's folks. I would love to be a part of it too :D

Hi, I am from Poland (currently living in the US) and I would like to join a team nodejs i18n team to help with translations.

HI! I would like to contribute to this project by offering a translation in to Spanish which is my native language. I work under the rules of Utopian-io and therefore I have to translate over a thousand words for it to be considered as a contribution. Let me know if/when you guys are interested and I'll gladly start working with you. CHEERS! 👍

#55 introduces code into this repository. It would be great if we could run tests on it. I don't know much about CI integration works in the @nodejs org.

As also discussed in the previous meeting
How shall we be translating and synchronizing the website contents?

It will be beneficial proposing a robust way of doing that with @nodejs/website-redesign and wrt nodejs/website-redesign#31

A centralized content repo for having contents for the website and i18n access and if @nodejs/website-redesign chooses a CMS for the same.

As mentioned in #14 (comment) — Incorporate https://github.com/nodejs/node/wiki/Intl#q-how-do-the-pieces-fit-together--how-do-i-know-who-is-responsible-for-the-bug into node docs ( possibly https://nodejs.org/api/intl.html or elsewhere ).

Example: nodejs/full-icu-npm#21 (comment) "the thousands separator is not what I expect"

(I pointed out the lack of communication between translators in #48. This is a follow-up issue for a project board.)
I have an idea that we launch the Slack Workspace for translators/proofreaders and link it from Crowdin. It is better to make the workspace public with slack-invite-automation and so on.

(If there is any problem to add this issue to the project board, please tell me 🙇)

from a standpoint of one translator/proofreader, I found some problem in Electron/i18n on Crowdin.
I hope such problems should be resolved in nodejs/i18n.

No rule for l10n

This problem occured in not only Electron but also other projects.
(Same problem bothered me when I was working on l10n of Android App.)

Ruleless translation usually make chaos in terms of choice of words, grammar, punctuation marks and so on.
Once l10n repo became chaos, it would be painstaking for contributors(translator/proofreader) to set some rules and fix problematic translations.

Styleguide for base(English) documents exists.
I think we need a "translation guide" for every language before starting translation project.

Some terms should not be translated.

Some technical terms(class names, properties, methods...) and sample codes should not be translated but some translators posted machine translated texts.
(FYI:Crowdin provides machine translation suggestion with Microsoft Translation API)

Crowdin can lock specified words to avoid miss translation, so we should designate such words before put files on l10n repo and Crowdin.

Lack of communication between translators

Crowdin has "Discussion" feature but it is not utilized. This is just a simple forum/BBS so not suitable for real-time communication. It may be one of the reasons that many contributors don't use this.

I have an idea; create Slack workspace for channels for each languages (#es,#fr,#ja,#zh-TW...) (and random channels like "#random_ru" might have a positive effect on community of translators.)

At least two active proofreaders are needed per language

there is a proverb "too many cooks spoil the broth" but "only one proofreader" is not sufficient.
so I think at least two proofreaders are needed to maintain translations. It is hard for single proofreader to proofread many new translations.

If you look at crowding files to translated https://crowdin.com/project/nodejs/es-ES# and the _toc_md https://crowdin.com/translate/nodejs/163/en-es you can see that TOC points to modules doc and other docs. In case of modules documentation, we need to prevent the translation of the module name which uses to match the filename and the first heading inside the doc, and for the other docs should be nice to have the same translation in the TOC entry and the document title.

We enabled https://crowdin.com/project/nodejs today. Let's make it easier for folks to discover the new Crowdin page.

Purpose

A continuation of this Node.js Community Committee issue.

Description

Since we're picking up steam with implementing a new i18n process, an audit of all of the existing Node.js l10n groups is in order to determine a few things:

• Is the group active, and/or would they like to continue the l10n group?
• Who're the currently active members, and/or who has expressed interest in pushing the group forward?

After the gathering of this information, we can then create issues regarding the following, and accomplish these (in sequential order):

1. Request that currently active group members (or people who'd like to resurrect a group, or start a new one) update their l10n group's membership lists, and add themselves to bring the group info up to date.
2. Agree upon a general procedure for l10n membership
3. PR a new membership procedure doc for every l10n repo
4. PR a how-to-contribute doc for every l10n repo–essentially outlining how to create a Crowdin Node.js l10n project and how to use Crowdin.
5. Archive inactive l10n groups and reduce the repo noise in Node.js

Crowdin has a glossary feature that presents translators with useful information about the terms they're translating (or should not be translating). Here's an example:

For nodejs/i18n, we should probably start with the following:

• node module names: fs, path, net, etc
• JavaScript builtins like Array, Boolean, etc. We can use the builtins module for this.

I've extracted our Crowdin glossary code from electron/i18n and created a new node module crowdin-glossary that we can use:

const glossary = require('crowdin-glossary')({
  project: 'nodejs'
})

Object.keys(globals.builtin).forEach(term => {
  glossary.add(term, 'This is a JavaScript builtin and should usually not be translated.')
})
 
glossary.upload()

For more info on Electron's glossaries, see https://github.com/electron/i18n/blob/master/contributing.md#glossaries

Since we haven't yet set up our Crowdin-GitHub integration, I was thinking we could walk through it together in our next working group meeting.

As a prerequisite, we'd need to make the @nodejs-crowdin GitHub user the new owner of https://crowdin.com/project/nodejs, instead of @obensource. That will allow multiple members of our working group to log in an administer the account. @Andrulko are you able to make this change for us?

PS When is our next meeting?

The current repo for Hindi translation and l10n is not maintained any more - https://github.com/nodejs/nodejs-hi
Please allow me to take over the repo and form a team for i18n Hindi translators and collaborators.

Targeted versions to be translated into #70
Primarily --

• [v4.x] - EOL - 04/18 - M. LTS ⌛
• [v5.x] - EOL 💀
• [v6.x] - EOL - 04/19 - A. LTS
• [v7.x] - EOL 💀
• [v8.x] - EOL - 12/19 - A. LTS
• [v9.x] - EOL - 06/18 ⌛
• [v10.x] - A. LTS - 10/18 🎂

Which all versions shall we be targeting for translations?
5/7 are dead, 4 is used at many places but LTS gonna die soon

Refer - https://nodejs.org/dist/index.json

Hi, I'm from Poland and I'm interested in contributing to nodejs. I do not have to much experience witch internationalization and open source in general, but I would like help this group in achieving their goals. So if you are able to accept not too experienced person, which want to develop their skills it would be great :-), if not at the moment, then maybe I could help with polish translations.

Regards

After a few months away from collaborating Node, I am starting to miss the work.

Why Richard

I'm currently writing a thesis on resources for endangered languages - see this repo - and I am interested in seeing if being a more active member of this group could help inform my own work, and if I can give back. I have an MA in Linguistics and am one thesis away from an MSc in Computational Linguistics. While I speak only English fluently, I can talk conversationally in seven other languages, and maintain several projects with translations. I wrote the dictionary for Na'vi from the movie avatar, and oversaw a community of five thousand learners and over a dozen different translations of the dictionary.

On the Node side: I am a core contributor, have been around for around half a decade, have hosted NodeSchools in several countries (often the first in that city), have been a member of the Community Committee in the past, and I run an open source company based in a large part on my experiences in node.

What's next?

What do you need from me for this to move forward.

Hi,

I did join the meeting just started but could not setup the zoom app on time. I would like to join the group and participate in i18n efforts.

npm's new ci command is supposedly much faster than a plain npm install. Let's give it a shot in update-source-content.sh

Check it out! https://github.com/nodejs/i18n/projects/1

Was thinking we could use this to start prioritizing issues. Could be useful during our meetings.

Let's meet!

We need to schedule a time to record our process for setting up the crowdin-github integration: #77

Let's make it happen before the Collaboration Summit! I'm generally available in the afternoons/evenings PST. How about y'all?

Now that @nodejs and @electron will both be integrating with Crowdin and facing some of the same challenges, I took a moment to make a new GitHub org for the Crowdin-related modules we're maintaining.

https://github.com/crowdin-modules -- I've invited a few members of @nodejs/i18n to join this org. If you didn't get an invitation and would like to join, please let us know.

• https://github.com/crowdin-modules/get-crowdin-file-ids has been around for a bit.
• https://github.com/crowdin-modules/crowdin-editor-language-codes I just wrote today.

Both of these modules exist to solve two unique parts of the same problem: Given a language and a filename, how do we get to the Crowdin editor page for that language and document? Crowdin may eventually add new APIs or alternative URLs that will render these modules unnecessary, which would be great! But for now they exist to help us move forward.

cc @Andrulko

Purpose

People who're interested in contributing translations don't have a place to land, or don't know how to get involved yet.

TODO

A good start will be having a 'Getting Started' doc that contains clear directives for joining l10n groups, which we can link to in our README along with a 'Want to help us with translation?' header.

Hi! i could contribute with Spanish and Thai translations (i guess Thai for documentation since all the coding is done in English).

When configuring Crowdin to integrate with GitHub, we should use a GitHub user account that:

• is not tied to any individual
• has admin access to this repo. (write is not adequate)
• has no other special privileges in the @nodejs GItHub organization.

This way if Crowdin were compromised and our i18n user's token was obtained by a bad actor, the affected surface area would be minimal, i.e. just this repo would be vulnerable.

@bnb as I recall, you may have some prior experience with this. Is there a protocol for creating users like this?

What

The next i18n meeting.

When

Tuesday April 10th 1400 UTC

See discussion here.

Agenda

• #19: l10n group audit
• #34: i18n WG Meeting Time & Frequency
• #48: Problems found in Electron/i18n from a standpoint of one translator/proofreader
• #50: Key based i18n vs default language i18n
• #59: Require status checks and reviews before PRs can be merged
• #58: continuous integration
• #60: new @crowdin-modules org
• #61: File structure and crowdin.yml
• #62: 'Getting started' doc for l10n group members
• #63: i18n: test plan

Where

We'll drop a Zoom link in this room when it is time for the meeting.

It's my understanding that the Node.js project may be using Crowdin as a localization platform. If so, I would recommend @Andrulko as a contact there. Andriy has worked closely with us on the Electron i18n project, and is generally quite responsive to our questions and requests. 🙏

I would like to contribute to Node.js portuguese internationalization.

I haven't used locize yet but Transifex has some really nice tools for managing i18n. We would split our i18n needs into assets and there's a dashboard to track the percentage of translation for each asset in each supported language.

Purpose

We'd like everyone involved in our WG to have the same understanding of what's going on, and be able to have the same opportunity to weigh in on every decision we make–without being held back by a language barrier.

Description

As @RichardLitt brought up in the discussion around our first i18n WG meeting: It would be advantageous to start searching for "on call" translators for our WG calls. This is probably an achievable goal if we reach out to the community via CommComm, Twitter, and our l10n groups.

TODO

• Bring this up in the next CommComm meeting and seek help
• Reach out to the Node.js community via Twitter
• Create an issue in the l10n groups who represent the same language preferences as the members of our i18n WG.

Time 🕓

I propose we hold a regular WG meeting every Tuesday at 4PM-5PM UTC. – It would seem that time might work for the majority of us (or at least I hope).

Frequency ∿

Should we follow the standard Node.js WG pattern and maintain a weekly meeting?

I imagine meeting weekly will be beneficial over the spring and maybe beyond while we're doing a lot of implementation. I suppose we can opt to meet bi-weekly if we perceive that to be best at any point.

There usually is two camps when it comes to manage i18n. Using a default language (usually english) or using keys (also usually in english but they are more like variables).

Has there been a decision on which one to use already?

Which all languages shall we be targeting initially?
There are ton languages 💥 available with Crowdin https://support.crowdin.com/api/language-codes/

Some Commonly translated languages and top languages visited on the website (ref. analytics https://github.com/nodejs/website-redesign/issues/15#issuecomment-369827787)

• Chinese Simplified - zh-CN
• Chinese Traditional - zh-TW
• French - fr
• Russian - ru
• Portuguese - pt
• Spanish - es
• German - de
• Japanese - ja
• Hindi - hi
• Arabic - ar
• Indonesian - id
• Italian - it
• Korean - ko
• Polish - pl
• Turkish - tr
• Ukrainian - uk

Amendments highly entertained. 😄

thanks

Interested in contributing to nodejs, since I'm using it for more than 4 years. I think this will be the right place to start with.

As part of #92, we'll need a shared npm user (or npm organization) for publishing the module.

@bnb @rvagg is there any precedent for this?

This is a followup to #55

I think we should enforce a review requirement on this repo using protected branches. We could also use GitHub's CODEOWNERS feature to ensure that the right teams and people are able to review pull requests before they ship.

why it's automatically creating new keys inside my locale.json file if key not found ?

For example I am trying to convert my whole object array using i18n but what's happening is it is creating new keys that already not added.

Is there any way to prevent this behaviour ?.

We will likely be supporting localization for multiple versions of Node.js documentation. From one version to the next, e.g. 9.9.0 to 9.10.0, there may be very few changes in the overall content. Rather than relying on translators to re-translate the entirety of Node's documentation from one version to the next, we can use a Crowdin workflow that will automatically apply existing translations from its Translation Memory.

Prior art: electron/i18n#135

Hi,
I am interested into join to the translation group for Portugues.

Node.js should be tested against industry tests to verify compatibility for i18n.

Old info:

• https://github.com/caridy/node-intl-testsuite has a way to run the 262 tests against node
  • Background: nodejs/Intl#15 / nodejs/Intl#13

Newer:

• https://github.com/bterlson/test262-harness
• https://github.com/tc39/test262/

Maybe the above are already run against node now?

Time

UTC Tue 06-March-2018 16:00 (04:00 PM)
What is 4PM-UTC In your local time?

Links

• Minutes Google Doc

Current Members

@amiller-gh (Adam Miller)
@Toinane (Antoine Olivier)
@obensource (Ben Michel)
@Tiriel (Benjamin Zaslavsky)
@maddhruv (Dhruv Jain)
@JCMais (Jonathan Cardoso Machado)
@lukaszewczak (Łukasz Szewczak)
@rachelnicole (Rachel White)
@rajzshkr (Raja Sekar)
@RichardLitt (Richard Littauer)
@ryo-a (Ryo.A)
@sotayamashita (Sam Yamashita)
@srl295 (Steven R. Loomis)
@TiagoDanin (Tiago Danin)
@vanessayuenn (Vanessa Yuen)
@Volem (Volkan Nazmi Metin)
@zeke (Zeke Sikelianos)

Agenda

General Logistics

• #34: WG meeting time & Frequency
• #30: Translators for our WG meetings
• Regular WG meeting issue owner (generate issues for our i18n WG meetings)?
• Regular WG Meeting minutes taker?

Reports

• #36: Initial i18n team meeting with Crowdin
• ECMA-402 & Unicode Standards update (ICU, CLDR) - @srl295
• Anything else?

Current Initiatives

• #19: Audit of our l10n groups
• Getting our i18n module going & what we can build right now (Outcome: generate an issue)
• Crowdin Integration (Outcome: generate an issue)

Joining the meeting

• Video call link will be provided for participants a few minutes before the meeting starts
• A live YouTube stream link will be shared a few minutes before the meeting also.

When @vanessayuenn and I implemented #55, we chose this directory structure for content:

/content/{nodeVersion}/{languageCode}/doc

for example:

/content/v8.11.1/en-US/doc
/content/v9.10.1/en-US/doc

Now that I think about how we'll write the crowdin.yml file, I'm wondering how we can account for multiple Node.js version directories without having to rewrite the YML file every time we change the list of target versions.

In other words, wondering how we can avoid this:

files:
  - source: /content/v8.11.1/en-US/doc/**/.md
    translation: /content/v8.11.1/%locale%/doc/**/%original_file_name%
  - source: /content/v9.10.1/en-US/doc/**/*.md
    translation: /content/v9.10.1/%locale%/doc/**/%original_file_name%

And do something more like this:

files:
  - source: /content/**/en-US/doc/**/*.md
    translation: /content/**/%locale%/doc/**/%original_file_name%

@Andrulko will this work?

It's time for another meeting folks! I know that the last meeting was at a poor time for the California folks, so let's set it in favor of them this time, following #34 (comment). Does this time work for everyone?

• PST: 8 AM - 9 AM
• EST: 11am-12pm
• CET: 6am-7am
• CST: 1pm-2pm
• JST: 12pm-1pm

Agenda

• continuous integration #58
• Translation languages #70
• Versions to Translate #71
• website content to be translated #72
• Set up the Crowdin-GitHub integration together, and record it #77
  New project board #82

Edit: Added agenda and also changed time