[Feature Request] Introduce a way to ignore regional dialects in the redirect plugin

[TiEul]

What problem does the feature solve?

I would like to be able to forward users with browsers that indicate user preference for a specific dialect (for example, pt-BR vs pt-PT or de-DE vs de-AT) to still be redirected to the overall language even if the specific dialect does not have a locale on my VuePress instance. I found that under some circumstance, users with certain dialect preferences are not forwarded properly otherwise. I think seeing the correct language is probably better in most cases even if the dialect does not match.

Proposed solution

I have created a pull request which introduces the non-backwards breaking variable fuzzyLocales. When enabled, the redirect plugin will do another check if it cannot find any matching locale. The second attempt will ignore the regional parts of the user language preference, resulting in a redirect to the correct language even if the region is not an exact match.

[TiEul]

@meteorlxy I have thought about this again and there is no need for any variable so I made a new PR which simply uses the code all the time. There is no real use-case where you would want to forward Spanish speaker to an English version of the documents just because a specific Spanish dialect was found, for example. See PR #42 .

[RikkaW]

The language tag is not just "language-region". I think it’s better to use something like bcp-47 to parse language tags and write a more formal algorithm to determine the final tag. But I'm not familiar with front end technologies, so I don't know if it's possible (I don't even know how to copy this plugin and run locally).

[TiEul]

The language tag is not just "language-region".

I am fairly certain that this is the case when it comes to browser language preferences. For example, in the Firefox webpage language preference settings, when adding a new language, you can actually see the tags that Firefox will send for any given language / dialect and all of them follow the language-region pattern. The more complex systems are not used by browsers so there is no point in implementing a more complex parser (YAGNI).

And while I am not against your idea, I would still argue that this PR offers a rather simple and quick improvement over the status-quo.

[RikkaW]

Yes, I know browsers are using the language-region pattern, but the language of the site could be other patterns.

In my case, my site has Chinese languages. If I choose to use the language-region pattern, there are 5 locales.

Locale	Description
zh-CN	Chinese (Simplified, PRC)
zh-SG	Chinese (Simplified, Singapore)
zh-TW	Chinese (Traditional, Taiwan)
zh-HK	Chinese (Traditional, Hong Kong S.A.R.)
zh-MO	Chinese (Traditional, Macao S.A.R.)

Speaking of their differences, the biggest difference between Simplified Chinese and Traditional Chinese is the appearance of characters. A large number of characters are different. For the regions, the difference is basically the difference of words. There are also a lot of them, but much less than the characters.

For a normal website, having 5 locales of Chinese is not that necessary. And except the system, the browser, and wiki sites, no one does this. So the best choice seems to be the language-script pattern.

Locale	Description
zh-hans	Simplified Chinese
zh-hant	Traditional Chinese

To achieve the goal, I have to write my own algorithm to let "CN" and "SG" use "hans" and the others to "hant". So I want the plugin to provide this ability.

[RikkaW]

After writing this, I find maybe the best solution is to let the plugin expose the language selection part, so the user can do what they want to do.

[meteorlxy]

After writing this, I find maybe the best solution is to let the plugin expose the language selection part, so the user can do what they want to do.

Good idea. Current options of this plugin is not flexible enough for advance users.

Contribution welcome!

[TiEul]

@RikkaW I totally understand your issue, my website also contains Simplified and Traditional Chinese and Chinese speakers from different location are a key target group for me, so I am in the exact same position as you when it comes to solving that problem.

However, the change I propose is an immediate improvement over the status quo. While it's certainly not perfect, it does solve some issues immediately and after that's in, I'd be happy to move forward and also contribute more if the requirements for advanced features are clear.

The problem is that some browser will only send specific language codes like pt-br and pt-pt and in these cases, these Portuguese speakers are shown the English version of my website rather than the Portuguese version (which strictly speaking is pt-pt but even that is better than English even for Brazilian-Portuguese speakers) because the language directory is called pt only.

I really understand the need for more flexibility but my point is that the plugin fails at its core functionality right now as it's simply not automatically redirecting users to their preferred language in a lot circumstances. That's why I would propose to merge my PR and then look for a better solution in the long-term. Yes, it's not perfect but at least it redirects all users of a certain language to the language they expect to see.

@meteorlxy Is there anything I could do to get my PR merged or could you explain why it should not be merged? It's really important me as I want to use VuePress for more projects and this is the biggest issue I currently have.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.