How to Easily Switch Multilingual textlint Configurations in VSCode

[toramameseven]

Thank you for providing the excellent textlint and VSCode extension. I really appreciate your work!

Here is an idea: by creating a shared textlint project on the PC, it could be possible to easily switch between multiple language configurations using the textlint VSCode extension.

Background

Recently, documentation tools like hugo and astro have made it common to work with manuscripts in multiple languages. However, with the textlint VSCode extension, I need to manually switch the configuration file for each language, which is time-consuming as it requires opening VSCode settings and specifying the file every time.

Goal

• Easily switch between multiple textlint configuration files for different languages (e.g., .textlintrc_jp, .textlintrc_en, .textlintrc_cn)
• Use a shared node_modules directory for textlint core and rules

Recommended Directory Structure (Example: Windows)

C:\textlint\
  ├─ .textlintrc_jp
  ├─ .textlintrc_en
  ├─ .textlintrc_cn
  └─ node_modules\ (textlint core and rules)

Useful Command Examples

1. pickup textlint project

• Specify the textlint project folder (e.g., C:\textlint)
• .textlintrc_jp, .textlintrc_en, and .textlintrc_cn are registered as presets (e.g., as Textlint: Config Paths (Array))
  • For example, files starting with 'textlintrc' can be treated as configuration files.
• C:\textlint\node_modules is set as the Textlint: Node Path

2. select textlint config

• The above Textlint: Config Paths are shown as selectable options
• The selected config file is set as the Textlint: Config Path
• It would be convenient if this could be triggered by a simple action, such as double-clicking the textlint icon in the status bar

---

By using this approach, I can quickly switch textlint configurations for different languages in VSCode, making multilingual documentation workflows more efficient. Thank you.

[3w36zj6]

I find this use case quite interesting. In fact, I haven't seen many examples of textlint being used for multilingual documentation so far.
Perhaps what users really want is a mapping between glob patterns and config file paths? Since textlint core already supports specifying a config file, implementing this feature wouldn't be difficult and it would be more generic. For example:

"textlint.configAssociations": {
  "**/*.md": ".textlintrc_md",
  "**/*.en.md": ".textlintrc_en",
  "**/*.jp.md": ".textlintrc_jp"
}

In the future, it might also be interesting to implement multilingual detection logic or support managing multiple configurations directly in the core.

@azu What do you think?

[azu]

For the textlint CLI, the easiest way is to use a config file for each language, like this:

/ja/
  - .textlintrc.json
/en/
  - .textlintrc.json

Rules often differ by language.
So choosing the config per run is enough.
In practice, shared rules are few.

textlint --config ./ja/.textlintrc "ja/**/*.md"

This is similar to @3w36zj6's textlint.configAssociations idea.

I understand wanting a single config in a VS Code extension.
Pointing an extension to many configs can be a hassle.

For example, ESLint can apply different settings to certain files with the files option.

• https://eslint.org/docs/latest/use/configure/configuration-files#specifying-files-and-ignores

The Vitest VS Code extension reads the workspace config.
This lets it keep different settings in one file.

• https://marketplace.visualstudio.com/items?itemName=vitest.explorer

textlint keeps config simple on purpose.
So monorepo-style configs are not supported today.
If it stays simple to implement, we may add support.
For now, the status is TBD because use cases are not clear yet.

[toramameseven]

Thank you for considering this idea.

It seems difficult for the VSCode extension to automatically detect the language or file type and select the appropriate configuration file. With the CLI, this can be configured, which is very convenient. Since this extension is useful, I would be happy if I could easily switch Textlint: Config Paths manually.

To make this a more general-purpose feature, it seems necessary to consider more use cases.

Thank you so much.