Community-committee: Internationalization/Localization Working Groups

[jasnell]

One of the really great ideas emerging from the io.js fork days was the establishment of the various localization working groups (e.g. https://github.com/nodejs/nodejs-fr). These have found mixed levels of success but unfortunately do not get much attention from Core.

We've had some renewed interest (e.g. https://github.com/nodejs/node/pull/14665) lately in contributions for localized documentation.

I'd like to propose that responsibility for the Localization working groups be taken over by the @nodejs/community-committee. I think there's a real opportunity to do some amazing things and would like to see this effort get the love and attention it deserves.

[RichardLitt]

I think it makes sense for CommComm to be involved with the localization groups - it is our job to ensure that a global and multilingual community is maintained, and that no one is left out of work they'd like to do because of linguistic barriers.

I'm curious what exact responsibilities you're imagining, @jasnell. Are there recurring tasks that we should deal with, which aren't being dealt with, elsewhere? Who is currently responsible for organizing the localization groups? From what I remember hearing in Berlin, no one is currently doing this work. Am I right in that?

[jasnell]

The tasks are largely fostering, mentoring and onboarding contributors. For instance, I had two people come up to me at NodeSummit specifically asking how to contribute translated docs. I didn't really know what to tell them or who to connect them with. These groups have never had adequate attention from core so I'm not even sure what else to suggest!

[RichardLitt]

Thanks. In that case - completely, 100% agreed. Let's throw this to CommComm.

[watilde]

I'd love to support this.

[mhdawson]

+1 from me as well. Getting the doc/info in place so more people canl promote/encourage participation in the translation groups would be great.

[vanessayuenn]

Would love to help on this as well! 😺

[RichardLitt]

At the fortnightly CommComm meeting, we talked about this a bit more. See minutes. That action items out of this are that me and @rachelnicole have volunteered to meet with @hackygolucky and members currently working on translation efforts to start the transition. We need to set up a date for this meeting.

[fhemberger]

Linking this related issue: https://github.com/nodejs/nodejs.org/issues/972
@sotayamashita (with GitLocalize) is working on establishing a translation workflow for editors.

[sotayamashita]

@fhemberger I appreciate that you mentioned me.

I am struggling to do it. It will take time to solve the problem between GitHub and GitLocalize. If we take too much time, I think I will give up integrating with Node.js at the moment but I will create an issue when we solve the problem.

Btw, I also can help localization.

[Tiriel]

Hey there,

I hope I'm not unearthing something too old.
As seen on the nodejs.org repo and on the nodejs-fr repo:
It seems that the French repo has been pretty dead for 2 years. We are actually 3, maybe 4 people willing to get back on track with the translation, but have currently no way of organizing ourselves.

We have started working on the translation a bit widly, but maybe it would be a good idea to get things done properly.

Cheers!

[rachelnicole]

Hey @Tiriel we would love to have you help out! I'm going to add internationalization to this upcoming weeks agenda again so we can discuss going forward now that we have more members of the community committee maybe we'll have more organizing volunteers. :)

[Tiriel]

Hi!

That would be great. It seems some are wanting to get to work without really organizing things inside the french translation group, and that works because there is only three of us, but I'd be glad to help anyone getting things more organized so we can plan and have more of a long term vision.

[watilde]

Here are my feedbacks and topics I'd like to hear opinions from comm-comm meeting.

We've tried for several times, but translating all of the API docs was too hard to catch up the upstream so it'd be out of the scope for now even it's super important. We might need to integrate a system first, like GitLocalize or crowdin. If we'd like have translated docs in the core, docs update should have something like semver which will be:

• patch update: no needs to update in the other language
• minor update: fix typo stuff
• major update: needs to translate

It'd make sense if the scope is only for LTS, but the initial translation is really tough.

For the community, or more like survey/event stuff, those kind of translation works were not much and that's what we should make more effort to reach to more people. I thought this Tracy's action is really good first step:

• https://github.com/nodejs/nodejs-ja/issues/121

I'd love to translate the questions of the survey itself as well in the case. With it, we can deliver the survey to more people who don't use English on daily basis and the number of them is incredible.

[sotayamashita]

@watilde

We've tried for several times, but translating all of the API docs was too hard to catch up the upstream ~ We might need to integrate a system first, like GitLocalize or crowdin.

I think it is very hard to keep translation ones update as well so we create GitLocalize but I would like to list the issue for translation we have before integrating those system.

[Tiriel]

Another thing to consider IMHO (though it may be a bit of self advertising, kind of...) :

Translating the API docs is indeed a great idea and a super important thing to do, but some people come on the website searching informations on the basic concepts when trying Node. But the basic presentation site isn't translated fully (nor does it have a propre language selector that I've seen). Before perusing through docs, having a good presentation of key concepts seems priority to me.

IMHO, before considering semver systems and integrations for translating the Docs, perhaps we should try and get the nodejs.org site properly translated? It seems it evolves less quickly than the docs, the work would be easier, and there are too few of us doing that right now for it to be fully translated to various languages.

But I'm new to all this, so it may not be the point and I'm off topic...

[watilde]

@sotayamashita @Tiriel I'd agreed. That's what I meant about it'd be out of the scope for now. Putting them in the core can be too hard and we might need a different approach like gettext which can have the translation source in the out of the core, but again it'd be out of the initial scope.

The thing is there are many things volunteer translators are feeling to make the API translation so it would be great if we can focus on website translation first as @Tiriel mentioned :)

[refack]

Happy to help as well

[rachelnicole]

We're discussing it in today's meeting https://github.com/nodejs/community-committee/issues/155

Myself, @obensource @amiller-gh are going to take actionable steps (tbd) to help move this forward by Nov 9th.

[refack]

/cc @amiller-gh

[refack]

@bablic might be willing to help as well

[Tiriel]

Couldn't follow all the meeting, not much service in the subway, but I managed to get @rachelnicole 's part on the subject! Great to see things moving, and again : count me in!

[sotayamashita]

@rachelnicole Oops. I missed the meeting. Could you invite me as a observer if we will discussing about it again. :bow:

[bnb]

Would pulling in the nodejs/internationalization repo, or creating a new one and archiving the old one, be helpful in pushing forward the internationalization effort?

[amiller-gh]

@rachelnicole, sorry for the radio silence! Just got back from a NYC war room and can finally move forward with non-LinkedIn things again. Any updates on collecting language use stats?

[obensource]

@amiller-gh @rachelnicole language use stats would be a great place to gauge language target priority, +1.

At this juncture it looks like we've established that GitLocalize is probably a good place to start with the translation process, but we need to triage our translation endeavors:

• Site
• Repo
• Docs

And then decide on actionable steps based on priority we've gathered from language use stats. Does that sound right?

[obensource]

@bnb I'd vote to pull it in, looks like a great place to start.

[Tiriel]

@obensource If yo'ure referring at the language use stats for the nodejs.org website, they wouldn't be relevant, since there isn't any language selection system atm.

On the other hand, if you're referring to general language use stats over the world/internet, I'm with you!

[obensource]

@Tiriel I'm referring to the general use stats yeah ;)

eg. figuring out how we can understand what the current global language use stats are and creating a continuous process around that so we can go from there, maintaining accurate viz. 🎉

If someone has already thought about this, or that work already exists, please chime in! 🙌

[Tiriel]

I'd say that's a good starting point yeah. But the size and activity of the community, at least here, should also be a factor I guess. Although, i18n communities aren't pretty active anyway for now...

[amiller-gh]

Hey all! (@rachelnicole, @Tiriel, @bnb specifically), spoke with the NPM folks and they were gracious enough to give us their language usage stats!

Yes, they don't have a language selection option, but they do collect the default browser language settings for all npmjs.com visitors. This gives us a nice snapshot of the Node community's language preferences.

I cleaned up the raw data a bit and found the top used languages on npmjs.com:

Language | Code | Usage
-- | -- | --
English | en | 67.15%
Chinese | zn | 7.25%
Spanish | es | 3.84%
Russian | ru | 3.37%
French | fr | 3.02%
German | de | 2.77%
Portuguese | pt | 1.99%
Korean | ko | 1.32%
Japanese | ja | 1.27%
Italian | it | 0.92%
Polish | pl | 0.91%
Indonesian | id | 0.66%
Dutch | nl | 0.66%
Arabic | ar | 0.64%
Turkish | tr | 0.60%
Sweedish | sv | 0.43%
Vietnamise | vi | 0.36%
Farsi | fa | 0.31%
Czech | cs | 0.28%
Thai | th | 0.25%
Ukranian | uk | 0.20%
Norwegian | nb | 0.19%
Hungarian | hu | 0.17%
Danish | da | 0.16%
Finnish | fi | 0.13%
Hebrew | he | 0.12%
Slovak | sk | 0.08%
Greek | el | 0.08%
Romanian | ro | 0.06%
Croatian | hr | 0.05%

Focusing on languages at approx. 1% or more is probably a good strategy moving forward, which nicely works out to the top ~10 languages in the list.

[Tiriel]

Hey! Thanks @amiller-gh , awesome work!

It does seem like a good approach, if we don't discourage other language communities from contributing the effort (which I know no one will).
On the other hand, Like I said, this may need some advertising, because for now the language communities are pretty near inactive for the most part.

I've been on traducting the nodejs.org website in French for some weeks, and although I do have some reviewers, I don't have any fellow contributors. The other community I've seen a bit active is nodejs-ja.

Anyway, maybe we should try and have some meeting to prioritize translation efforts, and how to get more translators?

[rachelnicole]

Can someone also help grab a list of the existing Node internationalization efforts that have repositories somewhere?

[Tiriel]

From what I've seen, there are lots of localized repos, but few efforts actually in the source code.

Some of the efforts in the source code actually don't have repos on their own, but they are at least in the nodejs.org repo.

Source code localization:

• english, obviously
• catalan (no repo yet?)
• german
• spanish
• french
• galician (minimal, no repo)
• italian
• japanese
• korean
• ukrainian
• chinese - continental

Other repos, not seen in source code:

• russian
• portuguese
• chinese - taiwanese
• indonesian
• norvegian
• magyar
• tamil
• turkish
• greek
• hebrew
• vietmanese
• hindi
• farsi
• finnish
• arabic
• bulgarian
• georgian
• swahili
• dutch
• polish
• macedonian
• dannish
• swedish
• malay
• bengali
• czech

If there are other repos/efforts somewhere other than that, I'm not aware of them.

[rachelnicole]

Thanks @Tiriel! wow. That's a lot. haha.

Ok, so I think based off the npm data we should focus on Chinese & Spanish initially. Once we find a way to have the process streamlined it'll be easier to roll out to the other languages.

What are we wanting to focus on first? Documentation / API stuff and the Website? Or is website internationalization a separate issue for the Web Site working group?

[Tiriel]

I agree on focusing on the two main languages. Though as I said, we may have contributions on other languages. I for one intend on continuing my translation work for the website in french (that's the easiest thing I can contribute to).

As I said before, I think we should focus on translating the website. The documentation/API changes too quickly for us to be efficient, at least with minimal teams and for a start. When we'll have thing rolling smoothly and bigger teams that may change though.

But I'm pretty new to all this, so my two cents may not be very accurate/worth much ^^'

[rachelnicole]

@Tiriel I don't want people to do manual translations. @amiller-gh spoke with the translation team at LinkedIn and we can automate a lot of the process, and then have people who are fluent be able to check for correctness.

[Tiriel]

@rachelnicole Oh okay, I was missing this information, sorry. I already got a PR in review on the website, so going to put it on hold.

[rachelnicole]

Also @Tiriel I think that translating documentation is really important. If we focus on LTS release, it could help with having something that's going to be stable for a bit / not changing TOO much.

[Tiriel]

@rachelnicole Indeed if the process can be automated it changes much things. Having the LTS API translated seems like a good idea.

But I think the LTS + WebSite should be the primary targets then, to test our ability on the matter. If it's okay though

[rachelnicole]

@Tiriel I agree! LTS Docs & Web Site.

[yoannmoinet]

Hi @rachelnicole,
shimming in to have more info.

That would be awesome to automate a bit of the process, just wondering which parts would that be, and how would that work?
I'm just afraid that, if we're talking about translations, it could give reviewers way more work reviewing automated translations than human made translations.

[amiller-gh]

So, I think I can help clarify a bit about LinkedIn and "automated translations" 😄

After Node Interactive, and hearing a little about our i18n needs, I thought: "Wait, we have a team at LinkedIn that translates our site into 28 different languages!". After sitting in on the CommComm breakout session I figured this would be an amazing non-code contribution that LinkedIn can make to the Node project.

Once home, I spoke with our translation team director/managers and talked them into the importance donating translation services back to Node.js! They were very eager to help and excited to contribute back to a project that is so important to LinkedIn's infrastructure.

The question is: To what degree will LinkedIn be able to support translations for Node?

My next approach to the team will include the usage numbers collected above, and a word-count for translatable content on both the Web Site and LTS Docs. (The i18n team scopes translation work by word-count). My ask will be for our i18n team to provide translations of both LTS Docs and the Web Site into the top 10 used languages. I expect we won't receive all of that – we need to see what LinkedIn is willing to actually willing/able to provide.

Once I get approval, and after work is complete for the first big-bang pass of translations, and assuming LinkedIn is interested in long-term maintenance of Node.js translations, we can think about ways to hook the site into LinkedIn's "World Server" – the bit of infrastructure that funnels content into our translation pipeline. Incremental updates to already existing translations would be submitted to the work queue automatically and would happen piecemeal, greatly reducing maintenance cost.

I wasn't going to publicly post about all this until I submitted a formal scope-of-work, received final approval, and knew exactly what work LinkedIn can promise – but since that may still be a long ways off (will probably include getting legal involved, director level sign off, etc) it makes sense to share earlier! (Thanks @rachelnicole for forcing my hand 😜 )

I'd like to re-enforce though, that __all this is only tentative until it is actually signed off on, and we don't know what LinkedIn will be able to provide until everything is submitted and approved.__ It is probably best to move forward business-as-usual until I get full buy-in from LinkedIn. But, even if/when this does happen, any and all work done beforehand will still be very valuable! It just means we can ask more of LinkedIn in other areas.

If anyone is interested in helping me get a translatable word count of the current website and LTS docs, I would love the extra pair of hands!

[Tiriel]

This is plain awesomeness! Thanks @amiller-gh !
@rachelnicole How do you see things? Do we keep translating/publishing/looking for people as before, or do we wait for an answer from LinkedIn?

[obensource]

@amiller-gh any response from LinkedIn yet?

[obensource]

@Tiriel @rachelnicole @amiller-gh as @bnb briefly mentioned before, archiving the existing nodejs/internationalization repo and making an established nodejs/i18n repo would be a good first motion to get us going. I was just going to create it and PR the appropriate links, but I don't have collaborator privileges yet so someone else will need to. :)

Stoked to discuss and get going with Chinese & Spanish translations for the website and LTS docs! 🎉

[Tiriel]

Hi there, going to ask here since we are currently working on organizing things.

There are currently some activity on the nodejs/nodejs.org repo, people submitting PRs for languages such as Catalan or Arabic. I know @rachelnicole wanted to put on hold all PRs for localization, so do we ask it formally to @nodejs/website ? Or do we let « non critical » language users submit PRs? Either way I’m in the website team, If there is need to pass questions/requests.
@obensource @amiller-gh @rachelnicole

[amiller-gh]

Hi all, sorry for the delay! Would highly recommend we continue on business-as-usual until we get full confirmation that we can rely on LinkedIn's contribution.

To push the linkedIn scope-of-work proposal forward, I would love some help getting the data requested in this new issue: https://github.com/nodejs/community-committee/issues/183. I've unfortunately been traveling the past 2.5 weeks and haven't been able to push it forward! Anyone interested in helping out? Comment over on https://github.com/nodejs/community-committee/issues/183 if you are!

[zeke]

Forgive the drive-by comment, but wanted to leave a note here about Electron's i18n efforts. We recently released a new internationalized site [1], and are using Crowdin [2] to power the translation process. Crowdin is free for open source projects, plays well with markdown, and integrates nicely with GitHub, creating pull requests on our i18n repo [2] automatically as new content is translated. Now that the new site is up, we're seeing the translation progress ramp up very quickly.

I haven't read this thread exhaustively enough to know what's on the table, but figured I'd share our experience, and I'd be happy to help out if needed.

1. https://electronjs.org/blog/new-website
2. https://crowdin.com/project/electron
3. https://github.com/electron/electron-i18n

[bnb]

@rachelnicole @obensource @Tiriel @amiller-gh @sotayamashita Would like to check in and see how things are going. Were you able to get a meeting set up? Happy to help assist - let me know if I can help y'all push this forward at all!

[Tiriel]

Hey!
We had a meeting scheduled last week but had to cancel it at the last moment (working schedules changed for half of us).
IIRC, we have a new one set for next week, on the 2nd. But I'll need @obensource to confirm, he's our organizing guru (and doing a great job at it).

[obensource]

@bnb as @Tiriel mentioned, things have been slow in December with schedules, holidays, etc, but it's going to pick up in January. Two meetings coming up: January 2nd, and January 9th.

Folks meeting on the 2nd:

• @obensource
• @rachelnicole
• @Tiriel

Folks meeting on the 9th:

• @obensource
• @amiller-gh
• @Tiriel

Meetings will continue to be organized as needed to push this forward. Going to be awesome. 😎

[ghost]

oh yeah - once this picks up steam, should it become a working group or a strategic initiative?

[obensource]

@pup I think it probably fits in the ongoing Working Group category. @bnb @rachelnicole: thoughts?

[bnb]

I think working group does fit, as there's a lot of autonomous work that would be done by the project. The CommComm also doesn't need to necessarily have a _say_ in the way that work goes, and as far as I can tell the CommComm does seem to be largely in favor of this and has a fair amount of confidence in the execution.

+1.

[rachelnicole]

+1 Working Group

[ghost]

yeah, i'm +1 on a working group as well

[obensource]

A couple of awesome updates for everyone tracking this issue:

• We recently published CommComm's proposal for moving forward with our new i18n effort–check it out!
• Our i18n working group is live!

Now I think I should restate was outlined in our proposal blog regarding our next steps–so everyone can be up to speed on the current WG conversation.

What we'd like to do next:

• Seek the approval of Node’s current i18n groups concerning the proposal.
• If successful, get the word out and ask our l10n groups for translation help–and request they might invite anyone who would like to join us in this.
• Begin building our new i18n module, conversing with Node.js core contributors and the TSC along the way–while also seeking help from people (like @zeke) who've blazed trails for successful i18n projects before us.
• Track the progress of our site redesign, and integrate.

[obensource]

Also, if you'd like to become a member of the i18n WG, let us know! 🙌

[sotayamashita]

@obensource I would appreciate if you could add me the WG

[obensource]

@sotayamashita

YOU! 😎

[sotayamashita]

@obensource I would appreciate your prompt response.　

[obensource]

i18n Update

The consensus seeking message for the proposal was reviewed by @bnb and I, and has now gone out to every Localization Group that @Tiriel listed above.

Next steps

• We set a consensus seeking period of one week.
• If by the 15th the motion is positive towards the proposal, we can move forward with setting up our Crowdin project, i18n module repo, and tackle other important tasks.

[sotayamashita]

@obensource

~ with setting up our Crowdin project

Is it a done deal?

[obensource]

@sotayamashita not yet, I wasn't planning on setting up an official Crowdin project until we have consensus, meaning we should do that after the 14th if we get the green light. We'll probably need to create a Node.js-owned Crowdin account, and go from there then.

Something super rad about that is that @zeke connected us to an awesome person at Crowdin to help get us going! https://github.com/nodejs/i18n/issues/5

[sotayamashita]

@obensource

~ setting up an official Crowdin project until we have consensus ~

I got it. Thank you for your quick response.

we should do that after the 14th

What will happen on 14th? Any meeting?

[obensource]

@sotayamashita 🍻🎉

We won't have a meeting on the 14th, but that is the official end of our consensus seeking period for the proposal. We should go ahead and schedule a i18n WG meeting as close to after the 14th as we can though–good call!

Anyone from our WG can get a doodle going with some dates & times: Feb 15–28th, and we can pick a time that works! 😎 (Or I can set that up too, either way)

[sotayamashita]

@obensource

I would like to confirm a few questions related to Crowdin

• Motivation
  
  
  
  • Would not be user contribution on GitHub. I think each translation will not be their commit on Crowdin. I am wondering whether user contribute to translation or not. I would like to hear @zake opinion.
  
  
• Permission
  
  
  
  • Is it OK to grant permission to read/write for public/private repositories under node/js? - According to their documentation. it says it will request to grant these permission. https://support.crowdin.com/github-integration/
  
  
• Availability
  
  
  
  • Is it possible to export translation data from Crowdin any time?
  
  

cc:/ @Andrulko

[Andrulko]

Hey @sotayamashita and @obensource, thanks for mentioning me here! :)

• Motivation

Translations in Crowdin are not saved as commits, but as suggestions. Many people can contribute at the same time and there will be automatic pull request with localized file sent back to GitHub. All translations made by collaborators together will be included.

• Permission

This is mandatory, otherwise integration won't be able to push/pull content. Connect GitHub account that has read/write permissions with Crowdin (it can be a separate user like "NodeJS_Bot" in GitHub/Crowdin. Then all incoming PRs from Crowdin will go from "NodeJS_Bot" name, should work good and everyone will know that translations came from Crowdin.

• Is it possible to export translation data from Crowdin any time?

Of course! It can be done via web interface / API / Console Client.

If you cannot connect GitHub account with Crowdin for some reasons, you can always use our CLI (https://support.crowdin.com/cli-tool/) to download content to your local machine and then push translated files to GitHub. Anyway, I think the direct integration with GitHub is better and worth to try!

Please let me know about any additional questions

[sotayamashita]

Motivation

All translations made by collaborators together will be included.

Does it means we cannot find who translated as an "Git" level?

Permission

This is mandatory ...

We have discussed about it before. https://github.com/nodejs/nodejs.org/issues/1235#issuecomment-304185227 We cannot approved the read/write permission for private repositories at that point.

Connect GitHub account that has read/write permissions with Crowdin ...

I would appreciate if you could show us any example :bow:

Is it possible to export translation data from Crowdin any time?

Of course!

Great :100:

[zeke]

Hey @sotayamashita, @Andrulko mostly answered for me above ☝️

Does it means we cannot find who translated as an "Git" level?

We were hoping to be able to associate Crowdin accounts with GitHub accounts, but it seems Crowdin does not expose an API for this, perhaps because it's personally identifying information and would be in violation of their terms? Not sure exactly. In any case, it would be great to be able to associate translation activity with GitHub users, but we don't yet have a good answer for that.

I would be happy to help work on ways to solve this. We could ask that all translators go through some kind of initiation process that ties their two accounts together. 🤔

Related: https://github.com/electron/electron-i18n/issues/108

[Andrulko]

Does it means we cannot find who translated as an "Git" level?

Commit with all translations will be done from the name of account that is linked with Crowdin. For example, if you setup integration as nodejs_bot, this name will be mentioned.

I assume the main idea is to mention all translators names/usernames who helped with translation? You can always generate & export Top Members report from Crowdin or automate this process with help of API:
https://support.crowdin.com/api/export-top-members-report/
https://support.crowdin.com/api/download-top-members-report/

Then you can publish this data in any place. Translators won't be forgotten 👍

We have discussed about it before. nodejs/nodejs.org#1235 (comment) We cannot approved the read/write permission for private repositories at that point.

Not a problem, you can start syncing files over CLI - I'll assist with setup

We were hoping to be able to associate Crowdin accounts with GitHub accounts, but it seems Crowdin does not expose an API for this, perhaps because it's personally identifying information and would be in violation of their terms?

Yes, it's because of privacy + not all users link their GitHub accounts with Crowdin + we push translated files to the repo, not strings and thus it's difficult to mention all contributors in the commit... The good news is that we already have possibility to push strings over API and it should give more freedom to integrate with various services.

Can't wait once we'll start testing something together soon!

[sotayamashita]

@Andrulko

Motivation

You can always generate & export Top Members report from Crowdin

I got it. Is it possible to get all translator with export-top-members-report or download-top-members-report API?

Permission

Not a problem, you can start syncing files over CLI

Awesome :100:

@obensource

I think when we use Crowdin, we need to configure a lot of things even if there is support. I just suggest you try to use GitLocalize. You just integrate with your repo.

However, I am an engineer for GitLocalize so my comment . It might be unbalanced suggestion so what about to try both of them for trial. I am looking forward to hearing from you

[Andrulko]

I got it. Is it possible to get all translator with export-top-members-report or download-top-members-report API?

Yes, all translators who did at least single contribution will be enlisted.

However, I am an engineer for GitLocalize so my comment . It might be unbalanced suggestion so what about to try both of them for trial. I am looking forward to hearing from you

Don't mind at all, it's good to try everything before making good decisions

[srl295]

@obensource I didn't realize that this had i18n as it's scope (much less its name!) until just now. I think it would make more sense to just rename Intl to i18n so that redirects work… 

Ref: https://github.com/nodejs/TSC/issues/353

[obensource]

@sotayamashita thank you for trying to sort through some of the tough questions here with @Andrulko & @zeke! 🙌

I think at this point, given that the accepted proposal was for using the Crowdin service and the overwhelming support we've received by our l10n groups & proposal readers was in support of that: it would be best to move forward with Crowdin.

I do (of course) want to remain platform agnostic in the interest of doing whatever is best for Node.js i18n, and we should consider all our options thoroughly. I do also think that given some of the points that were presented in the proposal, like the fact that Crowdin doesn't require our translators to have to navigate a complex Github UI, some configuration pain up front (as we're discussing here) is going to be advantageous in the long run in order to maintain an effective cross-discipline endeavor like this. Also, we have some people in our WG who've done this before for Electron–and they should be a great resource for us to get through the initial configuration quickly.

I am truly glad that we're already beginning to discuss these issues up front here, and excited to tackle them more thoroughly in our upcoming WG meeting. 🎉

[obensource]

@sotayamashita I do want to stress one more time that I really appreciate your perspective, and am thankful for you feedback on this. We need to keep our perspective open, and you're helping us do that. Many thanks! 🍻

[obensource]

@srl295 thank you for taking care of the Intl dechartering, and everything regarding that. Appreciate
it, and you! 🍻

[Andrulko]

I do not have words at the moment... Talk to you on Monday! 🎉

[obensource]

i18n Initiative Update 🌍 🌎 🌏

A lot of awesome things have been happening with our i18n initiative as we've continued to move forward. Here's a quick up-to-date for everyone! 🙌

Current Status

• The i18n proposal was met with a positive consensus by the Node.js l10n groups! We now have the green light to start implementing! 🎉
• Activity and interest for our initiative has been picking up in our i18n WG repo, and our team membership is growing! 📈
• The Node.js Intl WG has been dechartered. Now all Node.js Internationalization work will fall to the i18n WG.
• @zeke, @sotayamashita, and I are scheduled to meet with @andrulko (a Crowdin representative) on Monday to talk through logistics, and everything we need for configuration up front.
• We're going to audit our current l10n groups in order to determine their current status, and provide support.
• Our first WG meeting is coming up! We’ve got an open doodle that will be closing at the end of the day tomorrow, so please add your availability if you'd like to join!
• We need translators for our WG meetings. Let us know if you can help!

Thank you!

Thanks to everyone who's making this a reality, in every way! Excited to make it happen with y'all. 🍻

[obensource]

Upcoming i18n WG Meeting Date & Time

Our next meeting will be held on Tuesday, March 6th at 4pm (UTC).

If you'd like to join us, please follow the directions and activity in our team's discussion! 🙌

[obensource]

WG Meeting Date Correction: Our meeting will be on the 6th, not the 16th as I announced by mistake.

See you there! 🍻

[add1sun]

As a new contributor I came to this issue because it is tagged "good first issue" but it isn't clear what action is to be taken, especially by someone new to the project. :-) Could someone either summarize the action to be done or remove the label?

[Tiriel]

Hey! Thanks for bringing this issue up!

Actually, since the i18n repo has taken the work to be done on this side, I think this issue can be closed altogether.

The i18n initiative is now already launched and got some good steam, so if you want to give a hand on this side I think you'd better see directly in their repo. At any rate, we're always happy to have more people helping!

[obensource]

@tiriel I'm so excited to see this closed! 🎉🎉🎉

[arunamuthyala]

With i18n how can we temporarily change the locale for printing some receipt?
I have seen I18n.t("recieptBalanceInquiry", {locale: "fr"});
But this doesnt force the "fr" locale, when we already have a different existing locale in i18n.