Skip to content
This repository has been archived by the owner on Apr 5, 2022. It is now read-only.

FEATURE: Switch from flags to language names #61

Closed
twatzl opened this issue Aug 15, 2019 · 28 comments · Fixed by #80
Closed

FEATURE: Switch from flags to language names #61

twatzl opened this issue Aug 15, 2019 · 28 comments · Fixed by #80
Assignees
@VincentTam @twatzl
Labels
Status: Available Type: Enhancement

Comments

@twatzl
Copy link
Contributor

twatzl commented Aug 15, 2019

Bug Report

Problem description

I am from Austria. Although we speak German here our language and culture is different from Germany in a few aspects.

Our official locale as far as i know is de-AT, but when I use that for the translation it tries to load the flag flag-icon-de-at which does not exist.

Solution

A configuration possibility to configure the flag icon independently could solve the issue.

i.e.

flag: at

Workaround

I just use 'at' now as locale. Now the flag works, but I am not sure what else I broke in the process of doing so.
@twatzl twatzl changed the title QUESTION/BUG: Language flags not displayed for combined locales (de-AT, en-US) BUG: Language flags not displayed for combined locales (de-AT, en-US) Aug 15, 2019
@twatzl
Copy link
Contributor Author

twatzl commented Aug 15, 2019

Sorry for the confusing label. Initially thought this would become a feature request.

@pacollins
Copy link
Owner

For English, I created a merged flag under en.

In my opinion, the Language flags are more for a visual representation of the main language. I have seen merged USA/GB flags, but rarely merged other flags. If we feel like this is a big deal, it would be worth exploring, but ultimate, the languages are "English" and "German".

That being said, I am open to having a conversation about it.

@twatzl
Copy link
Contributor Author

twatzl commented Aug 15, 2019

Does using 'at' as locale have any negative impact for site users? For example because their browser does not choose the right language automatically.
If not I am fine with this workaround.

Although it seems a picky I do not really feel comfortable with using the German flag instead. After all it is a personal blog and I am not from Germany. This is especially true since 'Austrian German' can be quite different from German German.

For creating a merged flag you would need also to include Switzerland, since they speak German there as well, so it would get quite crowded in there ;)

Another workaround could also be to just add an option to disable the flags and have a language dropdown or something. But as I said, if my workaround has no negative impact then I am fine with that.

@pacollins
Copy link
Owner

pacollins commented Aug 16, 2019 •
edited
Loading

After thinking a little further, the easiest solution would be to add different locales to the style.scss here:

hugo-future-imperfect-slim/static/css/main.scss

Lines 761 to 773 in 6453583

/* Flags */
.flag-icon {
border: 0.02px solid black;
}
.flag-icon-en {
background-image: url(../flags/4x3/en.svg);
&.flag-icon-squared {
background-image: url(../flags/1x1/en.svg);
}
}

Your example would add:

.flag-icon-de-at {
  background-image: url(../flags/4x3/at.svg);
    &.flag-icon-squared {
      background-image: url(../flags/1x1/at.svg);
  }
}

That being said, if you are not translating your blog, you should just turn multilingual off and remove the flags. Either by disabling languages:

hugo-future-imperfect-slim/exampleSite/config.toml

Line 10 in 6453583

disableLanguages = [""]

or completely removing them from the config.toml:

hugo-future-imperfect-slim/exampleSite/config.toml

Lines 139 to 255 in 6453583

[Languages]
# Each language has its own menu.
[Languages.en]
languageCode = "en"
LanguageName = "English"
weight = 1
[Languages.fr]
languageCode = "fr"
LanguageName = "Français"
title = "Hugo Future Imperfect Slim in fr"
description = "Un thème de HTML5 UP, porté par Julio Pescador. Slimmed et amélioré par Patrick Collins. Multilingue par StatnMap. Propulsé par Hugo. "
weight = 2
[[Languages.fr.menu.main]]
name = "Accueil"
url = "/"
identifier = "fas fa-home"
weight = 1
[[Languages.fr.menu.main]]
name = "About"
url = "/about/"
identifier = "far fa-id-card"
weight = 2
[[Languages.fr.menu.main]]
name = "Blog"
url = "/blog/"
identifier = "far fa-newspaper"
weight = 3
[[Languages.fr.menu.main]]
name = "Catégories"
url = "/categories/"
identifier = "fas fa-sitemap"
weight = 5
[[Languages.fr.menu.main]]
name = "Contact"
url = "/contact/"
identifier = "far fa-envelope"
weight = 6
[Languages.pl]
languageCode = "pl"
LanguageName = "Polskie"
title = "Hugo przyszłość niedoskonała"
description = "Motyw HTML5 UP, przeniesiony przez Julio Pescadora i wzbogacony przez Patricka Collinsa. Wielojęzyczny przez StatnMap. Zasilany przez Hugo."
weight = 2
[[Languages.pl.menu.main]]
name = "Home"
url = "/"
identifier = "fas fa-home"
weight = 1
[[Languages.pl.menu.main]]
name = "O mnie"
url = "/about/"
identifier = "far fa-id-card"
weight = 2
[[Languages.pl.menu.main]]
name = "Blog"
url = "/blog/"
identifier = "far fa-newspaper"
weight = 3
[[Languages.pl.menu.main]]
name = "Kategorie"
url = "/categories/"
identifier = "fas fa-sitemap"
weight = 5
[[Languages.pl.menu.main]]
name = "Kontakt"
url = "/contact/"
identifier = "far fa-envelope"
weight = 6
[Languages.br]
languageCode = "br"
LanguageName = "Português"
title = "Hugo Future Imperfect Slim em português"
description = "Um tema do HTML5 UP, portado por Julio Pescadora e reduzido por Patrick Collins. Multilíngue por StatnMap. Feito com Hugo."
weight = 4
[[Languages.br.menu.main]]
name = "Início"
url = "/"
identifier = "fas fa-home"
weight = 1
[[Languages.br.menu.main]]
name = "Sobre"
url = "/about/"
identifier = "far fa-id-card"
weight = 2
[[Languages.br.menu.main]]
name = "Blog"
url = "/blog/"
identifier = "far fa-newspaper"
weight = 3
[[Languages.br.menu.main]]
name = "Categorias"
url = "/categories/"
identifier = "fas fa-sitemap"
weight = 5
[[Languages.br.menu.main]]
name = "Contato"
url = "/contact/"
identifier = "far fa-envelope"
weight = 6

@VincentTam
Copy link
Collaborator

VincentTam commented Aug 16, 2019 •
edited
Loading

Although it seems a picky I do not really feel comfortable with using the German flag instead. After all it is a personal blog and I am not from Germany. This is especially true since 'Austrian German' can be quite different from German German.

@twatzl Born and raised in 🇭🇰, a former 🇬🇧 British colony, I share similar feelings. Three months ago, a GitLab issue to merge Traditional Chinese locales 🇭🇰 zh-HK and 🇹🇼 zh-TW caused a storm in the teacup: https://gitlab.com/gitlab-org/rgitlab-ce/issues/60768.

It would be great if you could offer us some translations, even a few locale strings. They can be put into a pull request, which will be merged upon completion. The PR for Spanish translation #52 is an example.

For creating a merged flag you would need also to include Switzerland, since they speak German there as well, so it would get quite crowded in there ;)

😃 Good point! As a native 🇭🇰 Cantonese speaker, I can't agree with you more. The case for Chinese is even more illustrating: 🇲🇴 & 🇭🇰, 🇹🇼, 🇸🇬 & 🇲🇾.

Perhaps we can learn how to handle different locales from Minimal Mistakes: https://github.com/mmistakes/minimal-mistakes/blob/43b5e5f2ef115f3467fd4fa7256ca38953d5e993/_data/ui-text.yml#L518-L529.

If you really want to edit the SCSS rules, please be aware of the file path change in main.scss due to #57, in which the main SCSS file is automatically compiled into minified main CSS file.

@twatzl
Copy link
Contributor Author

twatzl commented Aug 17, 2019

@pacollins what about defining the flag string in the translation file? Because flag-icon-at already exists and works when you just name the translation file at.toml instead of de-AT.toml. This would basically resolve all those corner cases at once.

And in the *.toml file you would just define the flag with
flag: flag-icon-at and default behavior could remain unchanged if that property is not set.

And yes @pacollins I am using multilanguage feature. I write in German and English. This was the main reason why I switched from Hexo to Hugo and to this theme.

@VincentTam How would you recommend doing the translations? Should I just provide the same files for Austrian and German. After all the translations would probably be identical except for the flag. (The local varieties of the language are mostly different in the words for certain foods)

Should I just add 2 files with almost identical content?

@VincentTam
Copy link
Collaborator

I'm not (yet?) familiar with the working of the flag feature, so I'll leave @pacollins to respond.

@VincentTam How would you recommend doing the translations? Should I just provide the same files for Austrian and German. After all the translations would probably be identical except for the flag. (The local varieties of the language are mostly different in the words for certain foods)

  1. Fork this repo (online on :octocat: GitHub ).
  2. Clone any one of the locale files i18n/*.toml and name the clones as i18n/de-AT.toml and i18n/de-DE.toml (or more)
  3. Edit the double quoted string in other = "..." under each field.
  4. Review and commit into a new branch, say DE. You can choose whatever name for the new branch.
  5. Create pull request and celebrate 🎉.

Should I just add 2 files with almost identical content?

Why not?

TL;DR

In this case, developers would normally use one single de.toml file for them. By given the special situtation of this theme (languages got represented by regional/national flags, which is 🤔—what flag should I use for Cantonese, my native language? 🇭🇰 ? But Macau people 🇲🇴, ... also speak it, with some little differences of course.), I'll be open to the possible duplication of de-AT, de-DE, de-CH and de-BE, you name it. Anyways, provided that they are identical, that'll be stored in the Git repo as the same blob. Having a few more entries in the Git index can't hurt, since everything is compressed.

Having language + regional codes in i18n files shows our prospective users that Hugo's i18n supports regional (differences in) languages. IMO, that's a good sign. In case of new fields in the future, these identical files might evolve and diverge, just like our languages and cultures.

@twatzl
Copy link
Contributor Author

twatzl commented Aug 17, 2019

Ok. Fine. But I am going to wait until we have a proper approach for fixing the flag. I don't want to create a PR with a workaround. :D

@pacollins
Copy link
Owner

pacollins commented Aug 18, 2019 •
edited
Loading

@twatzl Wouldn't doing at.toml provide the wrong locale tag? Shouldn't the locale tag be de-at? That is where I got lost.

EDIT: Unless you meant at.toml had something like flag = "de-at" which we could then use as an i18n template on the theme (which might work, I would have to see a proof of concept).

@pacollins
Copy link
Owner

After experimenting, Hugo does not recognize de-at or at as a defaultContentLanguage.

Error: site config value "de-AT" for defaultContentLanguage does not match any language definition
Error: site config value "at" for defaultContentLanguage does not match any language definition

So this might be an issue to push further up the chain.

@pacollins
Copy link
Owner

pacollins commented Aug 18, 2019 •
edited
Loading

The work around that you are using seems to be appropriate based on my usage. For the line below, Hugo requires it be an ISO 639-1 Code which are 2 letter codes (eg. en, fr, de). Your options would be to leave this blank or use an applicable code.

hugo-future-imperfect-slim/exampleSite/config.toml

Line 2 in afbf3cc

DefaultContentLanguage = "en"

Then for the below lines, you can actually define it however you want. For example, you can replace fr with at at all locations, and the theme (and hugo) will function properly. Ironically, lang="at" validates while lang="us" does not.

hugo-future-imperfect-slim/exampleSite/config.toml

Lines 147 to 152 in afbf3cc

[Languages.fr]
languageCode = "fr"
LanguageName = "Français"
title = "Hugo Future Imperfect Slim in fr"
description = "Un thème de HTML5 UP, porté par Julio Pescador. Slimmed et amélioré par Patrick Collins. Multilingue par StatnMap. Propulsé par Hugo. "
weight = 2

That being said, I am going to close this issue because the current solution does not require changing the theme. It might be worthwhile posting an issue on the Hugo repo though about them expanding applicable language/locale codes.

Thanks for the brain teaser here and I hope this gives you some closure. 😄

Feel free to continue the discussion here though, if needed.

@VincentTam
Copy link
Collaborator

The work around that you are using seems to be appropriate based on my usage. For the line below, Hugo requires it be an ISO 639-1 Code which are 2 letter codes (eg. en, fr, de). Your options would be to leave this blank or use an applicable code.

🤦‍♂️

Cantonese isn't found in the linked list, but in ISO 639-3. Anyways, just a comment. Most Cantonese speakers can read from either 🇹🇼 zh-TW or 🇨🇳 zh-CN.

@martignoni
Copy link

You could also stop using flags to represent languages.

@VincentTam
Copy link
Collaborator

VincentTam commented Aug 19, 2019 •
edited
Loading

It might be worthwhile posting an issue on the Hugo repo though about them expanding applicable language/locale codes.

@pacollins I've started a question on Hugo forum. I've got a reply that Hugo actually support lang+country code from https://discourse.gohugo.io/t/i18n-support-for-language-country-code/20303/4?u=vincenttam. As a result, we might keep the flags. Here's the code in TOML.

Try:

languageCode = "de-at"

For a multilingual website you can use this:

defaultContentLanguage = "de"
[languages]
  [languages.de]
    weight = 1
    languageCode = "de-at"
  [languages.en]
    # …

In your baseof.html, you may try

<html lang="{{ .Site.LanguageCode }}">

@pacollins
Copy link
Owner

@VincentTam Let's explore that and see how it looks.

@martignoni I understand the sentiment, but its more about easy of access. Across the internet this is a common feature people are used to using. That being said, I am open to a suggestion as a replacement as long as it isn't an eyesore.

@pacollins pacollins reopened this Aug 19, 2019
@pacollins pacollins changed the title BUG: Language flags not displayed for combined locales (de-AT, en-US) Show language locales or switch from flags to an alternative solution Aug 19, 2019
@martignoni
Copy link

martignoni commented Aug 19, 2019 •
edited
Loading

@pacollins Re: flags do not represent languages. E.g. my country (Switzerland) has four official languages, but only one official flag. So it's maybe more than a sentiment. Anyway, you're right that the practice to use flag for languages is relatively spread in the Internet. So why not take this opportunity to make the Internet better? :-)

Some best practices here: http://www.flagsarenotlanguages.com/blog/best-practice-for-presenting-languages/.

And here's how I'm doing it in one of my (Hugo based) websites.
lang

@pacollins
Copy link
Owner

pacollins commented Aug 19, 2019 via email

@martignoni
Copy link

I would imagine a menu similar to this:

  • English (UK)
  • English (US)
  • Deutsch (AT)
  • Deutsch (DE)
  • Deutsch (CH)
  • Français (FR)
  • Français (CA)
  • Français (CH)

And possibly, if there's only one language variation, omit the info in the parenthesis.

@twatzl
Copy link
Contributor Author

twatzl commented Aug 19, 2019

@pacollins I am using at.toml. Probably I did not experience the issues you describe, because I am still using English as the main language for my blog and German just as secondary.

I think a menu as described by @martignoni would look nice. I don't see why the language choosing menu has to take up the entire right side anyway.

Regarding the issue of differentiating between languages in the written menu: I don't think this problem exists. The flag problem only exists, because I am Austrian and not German, but the language is still called German and nobody will translate it in all 3 languages. I have no idea how that is with other languages, but I think it is still save to say that either the languages are similar enough to be called the same and don't need translation or are different enough to have their own names.

@pacollins
Copy link
Owner

pacollins commented Aug 19, 2019 via email

@VincentTam
Copy link
Collaborator

We don't currently have any dropdown menus, so it wouldn't make sense.

After fixing #46, that would be possible with additional CSS settings, like my blog using Beautiful Hugo.

@VincentTam
Copy link
Collaborator

@twatzl Luckily, someone has already translated most of the UI strings for us:
https://github.com/marcelkraus/twietesla/blob/978fe99689adc1c38ce064f474ca554dfbcdfc1f/i18n/de.toml.

I've put this into #75. As I don't know German, I'm open to changes.

Regarding the issue of differentiating between languages in the written menu: I don't think this problem exists. The flag problem only exists, because I am Austrian and not German, but the language is still called German and nobody will translate it in all 3 languages. I have no idea how that is with other languages, but I think it is still save to say that either the languages are similar enough to be called the same and don't need translation or are different enough to have their own names.

Despite the similarities of these languages, I'm fine with creating locales like de-AT.toml, de-DE.toml, de-CH.toml, etc, but I'm experiencing technical issues in the linked Hugo Forum thread:
https://discourse.gohugo.io/t/i18n-support-for-language-country-code/20303/4?u=vincenttam.

I'll keep an eye on this because of my native written language: zh-TW 🇭🇰, which is quite different from zh-CN 🇨🇳. Dropping support for anyone of these

defaultContentLanguage = "en"
[languages]
  # Labelled "Chinese" for "Simiplified Chinese", no "Traditional Chinese" support
  [languages.zh]
    weight = 1
    languageCode = "zh-CN"
  [languages.en]
    # …

can cause sentiments, 👎 dislikes and complaints from thousands of netizens from these regions in case of big projects like GitLab: https://gitlab.com/gitlab-org/rgitlab-ce/issues/60768.

I would imagine a menu similar to this:

  • English (UK)
  • English (US)
  • Deutsch (AT)
  • Deutsch (DE)
  • Deutsch (CH)
  • Français (FR)
  • Français (CA)
  • Français (CH)

And possibly, if there's only one language variation, omit the info in the parenthesis.

@martignoni LGTM, but @pacollins has the final say.

@pacollins
Copy link
Owner

pacollins commented Aug 20, 2019 via email

@VincentTam
Copy link
Collaborator

VincentTam commented Aug 22, 2019 •
edited
Loading

@pacollins @twatzl @martignoni I appreciate the @pacollins' effort in getting the flags displayed on our theme, but @martignoni's suggestion enables us to support more regional languages/dialects. After spending two days on improving our theme's Germany, French, Polish and Potuguese support in #75, I realized the technical difficulty in handling custom/regional languageCodes like pt-BR, de-DE, etc. Consider lingua franca like Esperanto (which Beautiful Hugo supports) and Latin. What flag should we use for each of them? For the later, perhaps 🇻🇦 Vatincan's flag or that of Roman Empire 😆.

I would further simplify @martignoni's menu into

  • English (en)
  • Français (fr)
  • Deutsch (de)
  • Polski (pl)
  • Português (pt)
  • 正體中文 (zh-TW)
  • 简体中文 (zh-CN)

(Edited: fixed careless mistake in "Portuguese". I meant the name of the language express in the language itself with it's ISO 639-1 lang code in brackets, followed optionally by country-code.)

Untested suggestions:

P.S. If anyone can show us how his/her regional locale is different from the existing one, we'll be happy to accept a PR. For example, the following way to representing dates is an American one.

hugo-future-imperfect-slim/i18n/en.toml

Lines 1 to 2 in 118943a

[date_format]
other = "January 2, 2006"

Someone might ask for support for 🇬🇧 UK-styled dates. In this case, the list would be

  • English (US) (en-US)
  • English (UK) (en-GB)
  • Français (fr)
  • Deutsch (de)
  • Polski (pl)
  • Português (pt)
  • 正體中文 (zh-TW)
  • 简体中文 (zh-CN)

For backward compatibility, we might need i18n/en-US.toml, i18n/en-GB.toml and i18n/en.toml. For each page, we might need simlinks content/blog/post/foo.en-gb.md and content/blog/post/foo.en-us.md pointing to content/blog/post/foo.md.

Related Hugo Forum question: https://discourse.gohugo.io/t/i18n-support-for-language-country-code/20303/6

@pacollins
Copy link
Owner

pacollins commented Aug 22, 2019 •
edited
Loading

Sounds good. Lets go ahead and begin developing this change? (Volunteers? @twatzl? @martignoni? 😄) Once we get a framework set, I am happy to advice on the css.

  1. Switch from flag to text, per @VincentTam.
  2. Remove flag resource (css and images) references and files
  3. Begin styling new menu (do we want to wait for BUG: Menu code doesn't follow Hugo docs #46? or just match what we have now?)

@VincentTam - I don't think we will run into issues with backwards compatibility too much. I think in that case we will just release as a breaking change or find a way to create a pop-up warning when the site is localhost and console log to update deprecated features and provide a 2-3 month warning.

@pacollins pacollins changed the title Show language locales or switch from flags to an alternative solution FEATURE: Switch from flags to language names Aug 22, 2019
@pacollins pacollins added this to the 1.1.0 milestone Aug 22, 2019
@twatzl
Copy link
Contributor Author

twatzl commented Aug 22, 2019

Sure. If I find some time I'd be happy to help you. Do we have any means for communication other than this issue thread?

@VincentTam Be careful with CSS dropdowns though. I used that with Hexo, before I ported my blog over to Hugo and they do not work on mobile (because there is no 'hover' event) and I spent a whole day trying to fix it, but could not manage to get it done.

For this reason I would split it into 2 steps. Step 1 change the current menu from flags to languages, Step 2 change the sidebar menu to a dropdown. That way we can still decide to stick with the current solution if changing it causes too much trouble.

@pacollins
Copy link
Owner

For this reason I would split it into 2 steps. Step 1 change the current menu from flags to languages, Step 2 change the sidebar menu to a dropdown. That way we can still decide to stick with the current solution if changing it causes too much trouble.

I fully agree that there should be separate PRs.

Do we have any means for communication other than this issue thread?

We prefer to keep it all on GitHub for posterity (in case someone else has the problem). We aren't bothered by double comments or extra commits. That being said, if you really want another means, I can hook you up with my email.

@VincentTam VincentTam self-assigned this Aug 22, 2019
@VincentTam VincentTam mentioned this issue Aug 22, 2019
Merged
7 tasks
@VincentTam
Copy link
Collaborator

Sounds good. Lets go ahead and begin developing this change? (Volunteers? @twatzl? @martignoni? smile) Once we get a framework set, I am happy to advice on the css.

  1. Switch from flag to text, per @VincentTam.
  2. Remove flag resource (css and images) references and files
  3. Begin styling new menu (do we want to wait for BUG: Menu code doesn't follow Hugo docs #46? or just match what we have now?)

First two steps done in #80. Click to see the screenshot. I've never studied CSS, so what you see in the screencap is simply a temporary layout.

@pacollins pacollins mentioned this issue Nov 18, 2019
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@VincentTam VincentTam

@twatzl twatzl

Labels
Status: Available Type: Enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

⚑ → Language list VincentTam/hugo-future-imperfect-slim
4 participants
@martignoni @VincentTam @pacollins @twatzl