[feature request] The file path & route of default language and others should be flat

[Dafrok]

Version

^0.7.1

Description

I think this feature is necessary. It makes finding files easier ,the management of files clearer, and developers can simply customize a welcome page through docs/README.md or just redirect to the index of language en as default page if needed.

Config

module.exports = {
    locales: {
        '/en/': {
            lang: 'en-US'
        },
        '/ja/': {
            lang: 'ja-JP'
        },
        '/zh/': {
            lang: 'zh-CN'
        }
    },
}

Expect

docs/
  - .vuepress/
  - en/
    - foo/
    - qux/
    - api.md
    - README.md
  - ja/
    - foo/
    - qux/
    - api.md
    - README.md
  - zh/
    - foo/
    - qux/
    - api.md
    - README.md
  - README.md

Now

docs/
  - .vuepress/
  - foo/
  - ja/
    - foo/
    - qux/
    - api.md
    - README.md
  - qux/
  - zh/
    - foo/
    - qux/
    - api.md
    - README.md
  - api.md
  - README.md

[ycmjason]

I start to realise the issue that you are experiencing. I have looked into it and looks like it will require some major refactoring. @ulivz do you think we should facilitate this?

[Dafrok]

Or, if #290 (comment) is not a bug, is there any ways to disable the language selector in specified pages?

[ulivz]

We don't plan to change the implementation for i18n, but this feature can be done via priority route after plugin API was released.

For now, you can test this by these steps

1. Cloning VuePress's repo.
2. Add following redirect at the top of routes in lib/app/.temp/routes.js:

{
    path: "/",
    redirect: "/en/"
  },

3. Create a empty README.md at root directory (Used to generate root index.html which makes static server work.)

4. Test your i18n structure.

[Dafrok]

It's OK.

[GrayedFox]

Perhaps this feature request could be restated as:

"Allow user to have a flat file structure for multiple languages by giving them the option to pass in redirect path"

Config

module.exports = {
  redirectPath: "/en/"
}

Expected

Docs would need to be updated with description of config switch: used to redirect traffic coming from the root path to another directory.

Useful if you would rather have a flat folder structure for all of your languages, i.e.

docs/
  - .vuepress/
  - en/
    - foo/
    - api.md
    - README.md
  - zh/
    - foo/
    - api.md
    - README.md

instead of

docs/
  - .vuepress/
  - foo/
  - api.md
  - README.md
  - zh/
    - foo/
    - api.md
    - README.md

The blank README.md at the root directory should be autogenerated if it isn't present - this way users need only add the config option.

Not sure what to do in case one is present? Could offer a warning that the readme there is for redirection
purposes only and thus content will not be accessible due to redirects?

If you like this idea, re-open this issue and I'll make a PR 😸

[GrayedFox]

@Dafrok what do you think of the above suggestion?

[Dafrok]

@GrayedFox LGTM

[GrayedFox]

Ahoy, I am still planning on implementing this - first attempt (at getting it to be done during the build process) was unsuccessful - so I next attempt will be to take a more bootleg approach and try to update the .temp/routes/.js in a post-install script sort of way

[ulivz]

Since the existing i18n model has taken root, now, and for the foreseeable future, we are not going to modify the default i18n mode.

Of course, if you are passionate about your own model, consider using the plugin API to custom this during build time.

[yuriguimaraes-hotmart]

This is really needed for those who want to automate the translation/localization in orgs.

As an example: https://docs.transifex.com/transifex-github-integrations/github-tx-ui#linking-a-specific-project-with-a-github-repository

Transifex uses a pattern of [source-lang] > [target-lang] that uses folders or file patterns to automate the integration with repositories.

Although I can set a filter pattern for the target language, since source files are in the root folder above the target, is impossible to properly tell transifex a way to differentiate source files from target files since source nested folders are in the same level as the root folder for the target translations.

This is an example of the yaml config used for the integration:

filters:
- filter_type: dir
  file_format: GITHUBMARKDOWN
  source_file_extension: md
  source_language: en
  source_file_dir: docs/
  translation_files_expression: 'docs/<lang>'

If we have a structure like shit:

docs
├─ README.md
├─ foo.md
├─ nested
│  └─ README.md
└─ zh
   ├─ README.md
   ├─ foo.md
   └─ nested
      └─ README.md

Not only README.md , foo.md and nested/REAMDE.md will be considered source_language but also every single file inside zh.