Better language switcher

[jpanther]

Previous discussion in #462

There is a need to overhaul the language switcher and I want to improve it for everyone.

Unfortunately, I have been very busy in my day job and my workload has been too large to deal with this issue. I definitely want to fix it though and there's been a number of challenges for me to get there. As I think I've mentioned elsewhere, my intention is to make the language picker portable so that it can be placed in any menu. The changes I've been making over the last few theme releases have laid the groundwork for this however I'm still impeded by the time constraints of developing the last few components.

One of the biggest hurdles I have is actually having demo data to be able to test new i18n features. I don't have multilingual content in the example site and so I have to make a local development environment every time and set up dummy data for other languages. It takes a lot of time and doesn't reflect real use cases. This means that for me to be able to make changes, it's not as quick as just being able to test it against the large dataset of the current example site. It would be super helpful if the community could chip in here and perhaps we could get some of the sample content in the theme localised so that the example site has some multilingual content by default. It would not only help to demonstrate the theme features to new users, but it would greatly speed up the development and testing process. Having "real" data highlights potential issues far earlier than it does if I'm just creating shell pages to see if the translation features work.

The other issue is there are a lot of opinions on how this feature should operate. Some like the idea of a dropdown language picker, others like icons, some want it to be a top level menu and others want it buried in the hamburger menu. Implementing the feature in such a way that it is customisable is a key component but it's going to be difficult to please everyone. The mobile menu was exactly like this and it took time to come up with a workable solution that meets most people's needs.

I think the change I made to hide the current language wasn't thought out enough, and I expected to have more time to be able to quickly release incremental updates to work towards a longer term solution but I just haven't had the time. My options at this point are to roll it back or push forward knowing that it will take some time to get to the final feature release.

I'm going to keep this issue open as the main place to discuss this change as it will help keep me focused on implementing a solution. I'll link existing discussions to this page. Please post comments and feedback as it really helps me understand everyone's needs and wants.

[AntoineSoetewey]

Dear @jpanther,

Thanks for your reply. I totally understand that it takes time and your workload doesn’t allow to tackle this issue.

In the meantime, here are some thoughts regarding its position:

As far as I know, one person puts the language switcher in the footer (see #290), while most people would rather put it in the menu (see #462) and it seems the case for most multilingual websites.

It is true that it will be hard to please everyone, but I believe that we all agree that next to the site name is not ideal.
There is no perfect solution, but at the moment I believe that the majority would like to see it in the menu. So moving it in the menu (no matter if it is buried in the hamburger menu, as top level, icons or drop-down, etc.) would already be a huge improvement in the right direction.

Thanks again for your work and your consideration!

Regards,
Antoine

[max-alletsee]

It would be super helpful if the community could chip in here and perhaps we could get some of the sample content in the theme localised so that the example site has some multilingual content by default. It would not only help to demonstrate the theme features to new users, but it would greatly speed up the development and testing process. Having "real" data highlights potential issues far earlier than it does if I'm just creating shell pages to see if the translation features work.

Thanks for looking into the language switcher.

I could contribute by translating some sample content into German. In terms of scope, would we need only exampleSite/content/samples and the new config files for languages.en.toml and menus.de.toml or definitely the full site including the full docs?

[jpanther]

I'm really only looking for some sample content in different languages. Translating all the documentation is a much bigger project and then we'd have to try to manage the problem of keeping it up to date as the theme evolves. If the example site had translations for the homepage, menu, and the sample pages (even if it's only some of the sample pages), then I think that would be plenty to be able to test how the localisation works in a variety of places.

The example site content directory is already structured into subdirectories so it should be as simple as providing a translated index.[lang].md file for each sample page, along with the appropriate config files in the config directory.

[max-alletsee]

Thank you for your answer, @jpanther. This sounds very reasonable.
I would volunteer to translate the samples, homepage and menu into German. (Life is currently a bit difficult to plan, but I hope to work on this in the next weeks.)

[tomy0000000]

Brought here by @AntoineSoetewey from #290.

I have a production-ready blog at https://blog.tomy.me, which has a custom translation dropdown menu. The implementation can be found in tomy0000000/blog@a026989 commit, which is only 15 lines of code, yet it turns out to work very well as of now.

Since @jpanther also mentioned that there are more to be considered to make the widget customizable, I think it would be great to list out all the concerns here, so we (the community) can help work toward the goal, and I will have a more clear picture of how I can draft a PR.

[jpanther]

I like the idea of a dropdown menu and it could perhaps be styled with CSS to make it more in keeping with the overall design language. I also like the idea (as others have suggested) of having a single "translation" icon in the menu that will open a menu of language choices when they're available.

I want to be able to integrate this functionality with the menus config file in a similar fashion to how the appearance switcher works. This allows a great deal of flexibility for users because the link can be placed in a variety of locations depending on individual use cases. We could then include parameters that can further customise the appearance.

[github-actions]

This issue has been automatically marked as stale because it has not had any recent activity.
If you are still experiencing this issue, please review the issue history and add a reply with any requested and/or additional information in order to keep the issue open.
This issue will automactically close in 14 days if no further activity occurs.

[AntoineSoetewey]

This issue has been automatically marked as stale because it has not had any recent activity.
If you are still experiencing this issue, please review the issue history and add a reply with any requested and/or additional information in order to keep the issue open.
This issue will automactically close in 14 days if no further activity occurs.

Keep open :)

[jpanther]

Thanks to everyone for adding translations - it has helped immensely. I've finally got around to implementing this and have a working solution. I hope it will meet most use cases and I've tried to keep it very flexible. I'll be committing it to the dev branch shortly and anyone who wants to get an early look can have a play. Feedback is welcome, as always...

There's now a new menu action called locale and it will add a dropdown menu to any Hugo menu...

I've placed it top-right on the example site and I think this looks good but if you don't specify a position, it will default to the bottom-right in the footer. As it's a menu action it can be placed in any menu so it gives you options as to where you'd like it positioned.

[[main]]
  identifier = "locale"
  weight = 100
  [main.params]
    action = "locale"

It works the same way in all orientations and device sizes but I haven't done extensive testing beyond the devices I own so there may be edge cases that cause issues that will need to be patched up post release.

At the moment it's all pure CSS, which means there's no added Javascript or other bulky plugins, but depending on how things pan out, I might still have to add something based upon people's feedback.

As part of this change I dropped support for specifying a displayName and it now simply uses the official languageName parameter. I came to this decision because there's a lot of discussion around the internet about how to refer to languages and the prevailing consensus is to not use flags or other descriptions and to simply use the language name. And so that's what I'm doing - you can of course set languageName to whatever you wish and it will display it, but I didn't see the need to specify both that and an alternate display name.

While I was implementing this I also discovered that Hugo now has a languageDirection parameter and so I've now removed the params.rtl config param and replaced it with support for the Hugo default. This should make it easier for people adopting the theme when trying to read the official Hugo docs. Similarly Hugo now also supports proper case sensitive ISO language codes and so I've also been able to retire the params.isoCode parameter. It now picks up this value from languageCode natively, which is a nice bonus.

[AntoineSoetewey]

Thanks @jpanther for your work!

I have no particular feedback, except that I like the design and at the top right seems to me a very appropriate location.

Can’t wait to see the final version released!

[jpanther]

Although the commit closes this issue, I'm still happy for any general feedback in this thread. If you come across a new issue related to the functionality of these changes, please open a new issue for it.