Change:
[languages.de] title = "Kubernetes" description = "Produktionsreife Container-Verwaltung" <del> languageName = "Deutsch" </del> <ins> languageName = "Deutsch (German)" languageNameLatinScript = "German" </ins> contentDir = "content/de" <del> weight = 3 </del> <ins> weight = 8 </ins> ``` <ins> The value for `languageName` will be listed in language selection bar. Assign "language name in native script (language name in latin script)" to `languageName`, for example, `languageName = "한국어 (Korean)"`. `languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`, for example, `languageNameLatinScript ="Korean"`. </ins> When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value. For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)".

Discussion:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be updated Update languageName in to use both native and English alphabets (letter) for each language (except English). [ ] modify the localization guide document. (to mention a new recommended best practice for in each language block. in : using both their own alphabets and English alphabets (ex: ) if it is applicable. I'd like to suggest a format for consistency: languageName = " (Chinese)" languageName = " (Korean)" languageName ="Français (French)" languageName = "हिन्दी (Hindi)" ... Why is this needed The block for in configures multiple languages to the site. And parameter in each language block is used to show language menu on the website. ! Some languages (Chinese, Korean and Japanese) are using both their own alphabets and English alphabets in languageName (ex: ), but the others are using own alphabet only. This inconsistency issue was discussed in Kube SIG Docs localization meeting Monday 2/7, 2022. And we decided a new recommended best practice using both native alphabets and English (ex: " Korean") as it help folks who can't read native alphabet to know which language it is. Comments Related discussions: Kube SIG Docs localization meeting Monday 2/7:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
PTAL :)
Let me open a PR to modify the localization guide document. :) /assign
Looks good to me. Thank you <3
/area localization
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area localization Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hmm, we should add that label!

My suggestion: two fields. plus an optional second one . That will let us retain access to the actual localized if we need it.
thanks for writing this up I like Tim's suggestion of making this into 2 variables as well
/area localization
Thanks for the suggestion :) I hope to check your suggestion is about adding additional parameter () in the block for of For instance, If it is what you meant, I am not sure how works in Hugo. (I cannot find this parameter) Could you give me more context ?
I think would be a Kubernetes thing, not a Hugo thing. So long as Hugo lets us set it, we can then access that data in the theme and use it somewhere sensible.