Add internationalization feature

[kiaking]

related #628

VitePress Next don't have this feature yet. Let's implement it. While doing so, I would also like to suggest new config structure for locales option.

Currently, we must define two locales when defining multi locale site. One in app config level, and one in theme config level.

I think it's much easier to just be able to define locale on top level only.

export default {
  // Top level config for default and fallbacks.
  lang: 'en',
  title: 'VitePress',
  themeConfig: { ... }
  
  // All other locale settings.
  locales: {
    fr: {
      lang: 'fr',
      title: 'VitePress',
      themeConfig: { ... }
    },

    ja: {
      lang: 'ja',
      title: 'VitePress',
      themeConfig: { ... }
    }
  }
}

This should make typings much simpler too (maybe). It should eliminate weird situation like in #628 🤔

Also, maybe not required for 1.0.0 release, but consider #291 as well.

[euaaaio]

Yes, it’s a bit weird. When you create a custom theme with two languages, the localePath of useData() will be broken until you explicitly set themeConfig.locales.

[xfq]

FWIW, W3C has a Developing Localizable Manifests document (since .vitepress/config.js is also a manifest file).

[brc-dd]

Let's also track #902 and #955 here.

[fvsch]

Is the intent for RTL layouts to use CSS logical properties?
I could work on that for the default theme, if that helps.

[trincadev]

I think this issue is related to #41

[Zhengqbbb]

@brc-dd I'm ready use the test package vitepress@npm:@brc-dd/vitepress@next in my website to support i18n. Thx u great work
And I noticed

Don't override themeConfig.algolia and themeConfig.carbonAds at locale-level.

That I have a question, Have some way to configure algolia search to support i18n
my config: en | zh
preview link: https://deploy-preview-80--cz-git.netlify.app/zh/
You can try search, it disappeared after I clicked it, sure my console should be warn it if it not support.

[brc-dd]

@Zhengqbbb Yeah the Algolia part is not properly implemented yet.

@trincadev Actually this issue is for v1 (alpha, formerly next), and #41 was for v0 (it had i18n support).

[MarkusKeck]

@brc-dd @kiaking Is there any update regarding this topic?

At the moment I need to have different .md files for each language, this results in different urls for each language, which can also lead to problems if you want to refer to your page from external sources, cause you already specify the language for the visiting person.

Is it possible to use the default browser locale for this and vitepress decides which language is needed and the .md files load the string from a json file for the current language like every other framework / library does?
The need to have the exact same page multiple times just for translation reasons increases the project files by a huge amount. (2x, 3x, Nx)

Something like this would be neat:

for .md files
[i18n](MY_SPECIFIC_TRANSLATION_LABEL)

for .js / .ts files
t('MY_SPECIFIC_TRANSLATION_LABEL')

Or the vue i18n plugin could be used (the guy who created the plugin also uses vitepress for documentation, maybe he can / wants to integrate it so it could be used natively with vitepress?):

https://vue-i18n.intlify.dev/
https://kazupon.github.io/vue-i18n/introduction.html

Ideally translations could be used in the .md files and .js / .ts files (like the sidebars / navigation bars), so no seperate files just for translation purposes are needed there either.

In my opinion this feature is one of the most important imiprovements on the milestone list for 1.0.0, as almost every vitepress project I have seen uses at least two languages. But I can only speak for myself.

As someone who uses vitepress with multiple languages, I can only say that an easy translation option would have a positive impact on productivity, maintainability and overall project size.

[lmtr0]

Hi there, whats the implementation status of this issue? is there a branch I can try out with the most advance features?