-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add textlint to enforce writing guide [i18nIgnore] #11812
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for astro-docs-2 ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Hi @jp-knj - I'm noticing that there are conflicts here that will need to be resolved. Also, the open discussion seems to be ongoing, so I'm not sure what the status of this is, and what we need to go further with this. How will we know that we want this? Maybe the first step is at least to resolve the conflicts here? |
e3c353d
to
fd4bfa7
Compare
05c53a8
to
5fd62c5
Compare
Thank you for noticing the conflicts. When you have a moment, could you take a quick look and let me know if there’s anything else we need before merging? I really appreciate your time, and I’m happy to make any updates. Thanks again! |
The core docs team discussed this a little more this week, and it seems like there is not much disagreement from current I would love if some of our contributors like @morinokami and @kyosuke were able to share opinons, either here or in the linked GitHub Discussion, just to make sure there's nothing we're not thinking about. But I think the core team's position is that if there are no objections from Japanese contributors, we are willing to at least try this and see how it goes! |
@@ -18,6 +18,7 @@ | |||
"lint:linkcheck:nobuild": "tsm --require=./scripts/lib/filter-warnings.cjs ./scripts/lint-linkcheck.ts", | |||
"lint:slugcheck": "node ./scripts/lint-slugcheck.mjs", | |||
"lint:eslint": "eslint .", | |||
"lint:ja": "textlint --cache --config .textlintrc.ja.json src/content/docs/ja/**/*.{md,mdx}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We’d probably want to run this on PRs where ja
docs are modified, so we pick up any issues in CI and avoid merging files with errors.
Thanks for the follow-up and for including me in the discussion! I’m supportive of introducing textlint for the Japanese docs. I think it’s a great step toward improving overall quality and easing the burden on translation reviewers. I’m not too familiar with how it’s used for other languages, but applying it just to Japanese docs, as suggested in the PR, sounds very reasonable to me. |
+1 for introducing textlint. From a reviewer's point of view, it would help streamline the review process by reducing the need to comment on writing style or punctuation choices. Just like English has style debates such as whether to use the Oxford comma, Japanese also has various style preferences. Some of these are mentioned in the Japanese style guide, but not everyone reads or follows them. By introducing textlint, we can automatically catch deviations from the style guide, which reduces the burden on reviewers and gives contributors more confidence when writing. (In general, many Japanese contributors tend to feel more comfortable when the rules are clearly defined, I think) Also, textlint was created by azu, a well-known developer in the Japanese JS community. The tool is widely used among Japanese developers. For example, one of my colleagues, who helps maintain the official Japanese translation for Vue and Vite docs, told me he also uses textlint. I think this shows the tool is reliable and well-suited for our needs. The main concern might be deciding which rules to enable. Reaching agreement on that will take some discussion, possibly on GitHub or Discord. If we skip that step, there is a risk that the tool gets added but ends up being unused. But if we take the time to agree on which rules to use, I believe the benefits will be worth it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jp-knj, could you address Chris's comment and add a CI job that runs textlint for JP files?
c6c7ee7
to
3f4a811
Compare
@yanthomasdev |
Lunaria Status Overview🌑 This pull request will not trigger status changes. Learn moreLunaria automatically ignores changes on specific PRs by adding a ignored keyword in its title. Found: You can change this by either removing the keyword above from the PR's title, or modifying the Tracked FilesNote The notes below indicate what would happen if the pull request is merged when triggering status changes. Since a ignored keyword was found in the PR's title, the status changes indicated below won't be applied.
Warnings reference
|
We have errors 🎉 I see that the CI message only shows this:
Can we have it log things directly in CI? Seems annoying to not display the details directly. |
b49fbeb
to
bb725c3
Compare
bb725c3
to
76ab7f9
Compare
Thanks, update them to show the details on CI https://github.com/withastro/docs/actions/runs/16610388038/job/46992130126?pr=11812 |
Perfect — thank you! Now just to fix those two issue I guess 🚀 |
Description (required)
This PR adds and configures textlint to enforce the Astro Japanese writing guide for our documentation. It introduces a new
prh.yml
file with terminology rules (e.g., 標準表記の統一やコロン「:」の検出) and updates the.textlintrc.ja.json
configuration to load those rules. contributors will receive automated feedback on terminology usage and formatting consistency in Japanese docs, reducing manual proofreading errors and ensuring a unified style.📁 Directory Structure
Related issues & labels (optional)
i18n