Closed alexandrtovmach closed 4 years ago
Good idea. 👍
Since the goal is to help contributors avoid wasting their time and energy, maybe we could intervene earlier in the process.
We could also use a git precommit hook to detect changes to translated files and warn contributors that they probably don't want to make those changes. There's a tool called husky that makes it easier to manage git hooks in a Node.js project.
👋 Hi everyone,
This is a very interesting topic, also it happened to me when I started with the translation of the web ".org" into Spanish. In my case I had translated a section of the entire website and uploaded my changes on github, after this Alex accepted my contribution and told me how I should contribute in the future, so my job was lost.
From my point of view I think there are three steps with which we can improve this workflow:
1.- A common guide for all the projects that can be translated, this guide should explain how the contribution workflow is (I think @alexandrtovmach is already working). We save time for several people, the translator and the review team if this workflow is fulfilled. 2.- If the translator ignores this guide, he clones the repository and makes translation changes, when trying to commit, husky (precommit rule) should warn him with a specific message and not allow the user to publish the changes. This way no one will have to review the translated content for a contribution made with a wrong workflow. We saved time for several people on the review team. 3.- We should not trust step 2. The translator can force the commit by modifying the husky configuration in local or with a flag via terminal. We must have a pipeline in Github Actions that runs the same test as a local husky. If there is an error in the execution of the pipeline, the NodeJS translation team should be notified in order to contact this user and clarify what happened.
What do you think?
I have worked with husky and Github Actions and maybe I can be of help with this. 😊
☝️ sounds good, @JoseJPR. To summarize:
Feel free to work on any of this! 🙏
@alexandrtovmach and @zeke I have created this issue 331 to work in it. [Closed]
Do you think it is right?
Thanks @JoseJPR but I'm not sure why we would need another issue since this one is already open. I do think it would make sense to break each of those tasks up into their own issues though, or open PRs for each individually.
Hi @zeke , you are certainly right. I'll create the information in each PR individually. So we have fewer issues.
Thanks for the tip!
Hi @zeke and @alexandrtovmach
I'm not sure that I have performed the correct steps (sorry if not so), but I have created a PR on the web ".org" with the improvements in the documentation that I think necessary for resolve the first check (introductory guide for translators).
We need to think about ways how we can protect translated content from updates through GitHub instead of Crowdin, and apply it to all translatable projects
My idea is to use GitHub Actions, to check PRs:
nodejs-crowdin
- passI'm not very experienced with GitHub Actions, so cannot be sure if it's possible, going to research.
@nodejs/i18n @nodejs/i18n-api suggestions?