Remove `i18n/zh` in Chinese contents since it's been outdated

[fujitatomoya]

see https://github.com/kubeedge/website/tree/master/i18n/zh/docusaurus-plugin-content-docs/current, several folders have not been updated for years. https://github.com/kubeedge/website/blob/master/i18n/zh/docusaurus-theme-classic/navbar.json seems like it was maintained up to v1.15 like a couple of years ago.

i highly recommend to remove unmaintained documentation because,

• maintainability: maintainers do not have extra bandwidth to support the other languages.
• pay attention mainline English documentation with concise and precise information as much as possible with high quality.
• out of dated documentation would lead the readers to wrong information or possible problems.
• translation is easy to do with AI tools such as ChatGPT, DeepSeek or so on. this work is not anymore for the documentation site to keep the static language specific pages.

[tannaya7]

Hi ,
I’m interested in working on this issue.
Before proceeding, I’d like to confirm:

• Should the entire i18n/zh directory be removed?
• Are there any related configuration files (e.g., Docusaurus config, navbar settings) that should also be updated?

I’m happy to take this up once confirmed.

Thank you!

[fujitatomoya]

@tannaya7 thanks for being willing to make contribution.

before making changes, i think we should have consensus for this. i am planning to next community meeting to bring this up. if you are interested, it would be nice to talk with you there. see https://github.com/kubeedge/community/blob/master/README.md#community-meeting

[tannaya7]

@fujitatomoya Thanks for the clarification!
I’ve taken a quick look at the i18n/zh directory and noticed that some parts haven’t been updated recently, while others (like the blog) were updated more recently.
I’ll wait for the outcome of the discussion and would be happy to help based on the agreed direction.

[Shelley-BaoYue]

Since the large percentage of KubeEdge users in China, directly removing Chinese docs might not be well-received. However, maintenance cost of Chinese docs is indeed a valid point for discussion. Perhaps we could consider other solutions, such as using AI tools within the CI to automatically generate or update the corresponding Chinease docs.

[fujitatomoya]

yeah this is just a suggestion, i do not have strong opinion on this.
but at the end, Chinese docs are way behind compared to the latest English doc, that is not good for readers either.

having AI tools would be nice to see, probably MCP to KubeEdge doc to plugin the AI tools or something like that.

[fujitatomoya]

today's conf call, i said i will add more context on this issue.

it is true that some CNCF projects support multi-language documentation in the doc repositories. but i think this is NOT good approach anymore with the following reason.

maintainers do not have extra bandwidth to support the other languages. we have dedicated person for the language to keep the documentation to be translated and catch up with the mainline English documentation. if we lose it, there will be inconsistency between specific language doc and mainline. this is always the pain and burden for the maintainability, which is not gonna work. (this has been proved already, multi-language page almost always show "this doc is not up to dated, if you want to know the latest documentation you see English one.")

instead, with this AI era, i highly suggest the different approach.

we pay attention mainline English documentation with concise and precise information as much as possible with high quality.
translation is easy to do with AI tools such as ChatGPT, DeepSeek or so on. this work is not anymore for the documentation site to keep the static language specific pages. how about MCP or plugin for AI tools instead to access and translate the language from kubeedge mainline documentation site?

[liyuerich]

I suggest keeping i18n/zh, and at the same time create i18n/en instead. make sense?

i18n
-- en
-- zh
-- ja
-- others language, if necessary

[fujitatomoya]

No that is not really my suggestion here.

i believe that documentation does and will evolve every day aligns with the implementation.
that means it would be hard for maintainers to keep up all the multi-language at the same time, this does not scale.
and if it does not catch up with main doc, there will be the conflicts between English main doc and other multi-language based doc, which is consistency problem.

instead, my suggestion again here is that, translation should be done on user's side. i believe this is much better for maintainers, maintainability, consistency and precision.