Some Suggestions and Questions on Localizations' changes

[SEWeiTung]

This article mainly focus on three things:

a. Do we need a "fast-track" verification for localization?
b. Where/How to discuss about localizations?
c. The "i18n group": do we still keep it?

Do we really need a "fast-track" verification rule in GitHub for localizations?

In the "CONTRIBUTING.md", we've got this rule:

nodejs.org/CONTRIBUTING.md

Line 128 in 43eedbc

- Fast-tracking is only allowed for small bug fixes, small feature changes, localisation changes, or other sort of non-critical/highly-impacting changes that are not covered by the previous rule that allows PRs to be merged immediately.

For code review at a small change, "fast-track" is OK and fine. Because it meets "verification" / "reviewing"——two very important functions in GitHub.

But I don't understand why we still need a "fast-track" in translations with 2 main reasons:

1. This is localization instead of code, it WON'T break the website's functions, even if it's something not suitable.

2. To verify whether a translation good or not ISN'T the task for GitHub! We're now using Crowdin instead to manage localizations, this means any approval/rejection will be processed through Crowdin instead of GitHub, and to decide whether the translation can be "passed" or not isn't relying on GitHub, because if some translation isn't well, Crowdin won't let it get passed by approver, and what's more: Only when approver has approved some translations is the translated article sent to the GitHub through the Crowdin within 24 hours automatically, so "GitHub" is now a platform for merging translations only WITHOUT functions of verifying/checking "right"/"wrong" translations——All in all, GitHub ISN'T a place for localizations' discussions/checkings, it's only the place to merge (sometimes for the manager to do the last review of the whole translations with few comments if possible).

Where/How to discuss about localizations?

Do we also need to create channels for translation on Slack, something like "@nodejs/nodejs-cn"? Two reasons for it:

1. It will speed up a variety of translators in the same country or area groupped together to chat and talk happily in the same channel (name can be something like "i18n-Simplified Chinese"...ect, this can be discussed later if you agree to create such channels).

2. "GitHub's Issues of Localizations" should be something to be planned or to get solved or suggestions to improve the localizations instead of talking about which translation is better, or for an unknown/rough/unsure idea, or how you can image if there're TOO MANY i18n questions on translations!

Last One

Do we really need nodejs's i18n group ? Since we don't have "@nodejs/nodejs-cn", at least the original group such as "@nodejs/nodejs-cn" or related parts of functions now disappears....Maybe the README.md there should be also changed to welcome the huge change of our website.

---

These questions and suggestions were written by me in heart carefully, after reading CONTRIBUTIONS.md and TRANSLATIONS.md and other related files without being mentioned about. So I begin to ask here to have a discussion, anything missing or misunderstanding, please feel free but kind to point out.

Thank you in advance for all:)

[AugustinMauroy]

Where/How to discuss about localizations?

For translated content and term to use in specific lang. We have Crowdin discussion.
For problems with crowdin we have Github.

The "i18n group": do we still keep it?

I18n sub-group was remove. There is only I18n left which is responsible for full-icu and tc-XX.

[AugustinMauroy]

Crowdin have inside discussion.

[SEWeiTung]

Don't u mean these discussions aren't related to Crowdin itself but the quality of nodejs's translations? Just for confirm only.

[ovflowd]

Yup, the aim for Crowwdin is to be a place where:

• We can do translations
• Discuss the platform features (through discussions)
• Discuss how we can improve translations (through discussions)
• Discuss best practices for translations.

About the last item, I honestly believe we need to create some guides for translations. Like links should be replaced with their localised versions, casing-preferences (should we do NPM or npm) and which words should not be translated and/or what (code blocks, technical words, etc.).

That'd be great if y'all can help me set up a Google Doc.

[comradekingu]

It would be more fruitful to do that with flags in Weblate.
https://docs.weblate.org/en/latest/admin/translating.html#translation-flags
https://docs.weblate.org/en/latest/admin/checks.html#custom-checks

If discussions weren't hidden behind a login and there was a strong community maybe, but other than that I have never
seen it done.

[ovflowd]

Discussions, indeed, are hidden behind a login for current translators.

Not sure what these links are supposed to be for us? Could you please describe better what you're suggesting here?

[ovflowd]

This is localization instead of code, it WON'T break the website's functions, even if it's something not suitable.

Malformatted Markdown can break the build. There's a reason Crowdin creates a PR, so we can sign-off and review the changes.

To verify whether a translation good or not ISN'T the task for GitHub! We're now using Crowdin instead to manage localizations, this means any approval/rejection will be processed through Crowdin instead of GitHub, and to decide whether the translation can be "passed" or not isn't relying on GitHub, because if some translation isn't well, Crowdin won't let it get passed by approver, and what's more: Only when approver has approved some translations is the translated article sent to the GitHub through the Crowdin within 24 hours automatically, so "GitHub" is now a platform for merging translations only WITHOUT functions of verifying/checking "right"/"wrong" translations——All in all, GitHub ISN'T a place for localizations' discussions/checkings, it's only the place to merge (sometimes for the manager to do the last review of the whole translations with few comments if possible).

I understand Crowdin has reviewers and approvers, but that doesn't prevent proofreaders for approving changes that can have unforeseen consequences.

It will speed up a variety of translators in the same country or area groupped together to chat and talk happily in the same channel (name can be something like "i18n-Simplified Chinese"...ect, this can be discussed later if you agree to create such channels).

Crowdin Discussions is used for all translation/localisation-related chatting, as @AugustinMauroy mentioned.

"GitHub's Issues of Localizations" should be something to be planned or to get solved or suggestions to improve the localizations instead of talking about which translation is better, or for an unknown/rough/unsure idea, or how you can image if there're TOO MANY i18n questions on translations!

Could you rephrase? I sadly didn't get what you mean here.

Do we really need nodejs's i18n group ? Since we don't have "@nodejs/nodejs-cn", at least the original group such as "@nodejs/nodejs-cn" or related parts of functions now disappears....Maybe the README.md there should be also changed to welcome the huge change of our website.

Node.js's i18n group isn't about translating the website. They're the i18n teams of the Node.js Core. Also, this repository is not the right place to discuss the utility of the i18n group

These questions and suggestions were written by me in heart carefully, after reading CONTRIBUTIONS.md and TRANSLATIONS.md and other related files without being mentioned about. So I begin to ask here to have a discussion, anything missing or misunderstanding, please feel free but kind to point out.

I appreciate you creating a discussion, but you could also easily have made these questions on Slack, merely because these sound like internal discussions for the team.

[SEWeiTung]

I appreciate you creating a discussion, but you could also easily have made these questions on Slack, merely because these sound like internal discussions for the team.

Yes, it's just considering internal discussions something formal, I'd send them to the GitHub's discussions instead of Slack, which seems like talks of fragmentations.

And what's more：There's a time difference between us, if I use Slack I'm afraid you'll have to wait for a long time to get a response from me because I cannot guarentee that I'll reply in time, which makes you feel puzzled or annoyed. And if there's an app of Slack in your mobile, maybe you'll be affected by noises if I send info in an async way——That's the reason why I don't use Slack.

But now, of course, if you don't care for it, I'll leave messages for you in private or public in an async way :)

[ovflowd]

Sorry, maybe I've diff understanding about GitHub's Issues of Localizations: I prefer taking it as a place to improve the translation foundations (tools)...ect, instead of pure translation problems. So that's the reason why I want to know whether we've got a place to discuss on quality of translations.

Again, if that's the topic, this repository is not the right place for it 😅 . The Next-10 working group and Documentation working-group work on bettering the state of docs. The tooling behind the API docs isn't even within this repository but on nodejs/node.

[ovflowd]

And what's more：There's a time difference between us, if I use Slack I'm afraid you'll have to wait for a long time to get a response from me because I cannot guarentee that I'll reply in time, which makes you feel puzzled or annoyed. And if there's an app of Slack in your mobile, maybe you'll be affected by noises if I send info in an async way——That's the reason why I don't use Slack.

The same applies to GitHub. The Timezone difference will not change. And asynchronous communication is a norm. I'm completely fine with waiting a few hours for your reply 😄

Anyways, I appreciate your intent, but for real, async communication is super normal for me :)

[ovflowd]

But now, of course, if you don't care for it, I'll leave messages for you in private or public in an async way :)

Please on public async way hehe 🙈 (We want everyone to be able to take a slice of the discussion).

And Slack is better because a lot of contributors get hammered with notifications over here

[SEWeiTung]

OK