vitepress

vitepress copied to clipboard

Is your feature request related to a problem? Please describe.

The property themeConfig.i18nRouting is complicated, a boolean value is not sufficient for general usage case.

Describe the solution you'd like

Please allow users to pass a function for the property themeConfig.i18nRouting, so that they can decide how 18nRouting is done.

Describe alternatives you've considered

No response

Additional context

No response

Validations

• [X] Follow our Code of Conduct
• [X] Read the docs.
• [X] Read the Contributing Guidelines.
• [X] Check that there isn't already an issue that asks for the same feature to avoid creating a duplicate.

Any suggestions on what should the API look like? We can allow pure functions. Will something like this work:

i18nRouting: (data: VitePressData<DefaultTheme.Config>, hash: string) => string

That is a nice idea: the return value serves as the dynamic routing result. It would be perfect, if the target locale config could be included into the arguments.

You may export your current (two) implements as (two) examplar configs.

It would be perfect, if the target locale config could be included into the arguments

Ah yeah right. You can access current locale from data.localeIndex.value and we can provide target locale as argument.

I'm interested in tackling this issue. I'm proposing the following API:

    i18nRouting?:
      | boolean
      | ((
          data: VitePressData<DefaultTheme.Config>,
          hash: string,
          targetLocale: string
        ) => string)

To illustrate its usage, here's an example implementation of a custom routing function that replicates the current default behavior:

  themeConfig: {
    i18nRouting: (data, hash, targetLocale) => {
      const langDir = (locale: string) =>
        locale === 'root' ? '/' : `/${locale}/`
      const barePath = data.page.value.relativePath
        .slice(langDir(data.localeIndex.value).length - 1)
        .slice(0, -3) // get rid of '.md'
      return `${langDir(targetLocale)}${barePath}${hash}`
    },
    …
  }

Let me know your thoughts!

Are you sure, using a function is more advantegous, than defining the target pages in a frontmatter, like in the proposed solution to #3532 ?

IMHO defining a translated target for each page is more transparent and provides better control, i.e. if a translated-link changes. The configuration is simply closer to each page.

For me, it IS tedious to add configurations for each single pages, while a handy structure is already present in the content folder.

Moreover, it is easier for users to adopt this configuration method.

Is sb working on this issue?

Is sb working on this issue?

I actually have a PR ready, which implements the interface I suggested, but I was waiting a mantainer's reaction before sending it.