Dashboard: Translation of kubernetes terms

[shu-mutou]

Disscuss about translation of kubernetes terms.

• Current status in each translations
• They should be translated, or not.
• How to define the words untransatable.
• etc.

[shu-mutou]

ja, fr and ko teams translates almost k8s terms for now.

[zehuaiWANG]

Thanks for @shu-mutou . First of all, in my opinion, the resource types in navigation bar should not be partially translated (they should be fully translated or not translated). Partial translation can make the whole UI strange. In fact, I agree with that they are not translated more, because kubernetes users know the meaning of these specific kubernetes resource type , and different people have different translation, so translating them may make others difficult to understand. Secondly, I think we should compile and run the dashboard after translation to make sure that UI / UX is correct and reasonable.

[zehuaiWANG]

the following is the word I think it should not be translated in navigation bar:

1. Cluster Roles
2. Namespaces
3. Nodes
4. Persistent Volumes
5. Storage Classes
6. Cron Jobs
7. Daemon Sets
8. Deployments
9. Jobs
10. Pods
11. Replica Sets
12. Replication Controllers
13. Stateful Sets
14. Ingresses
15. Service
16. Config Maps
17. Persistent Volume Claims
18. Secrets
19. CPU
20. IP

[shu-mutou]

Thanks for @shu-mutou . First of all, in my opinion, the resource types in navigation bar should not be partially translated (they should be fully translated or not translated). Partial translation can make the whole UI strange. In fact, I agree with that they are not translated more, because kubernetes users know the meaning of these specific kubernetes resource type , and different people have different translation, so translating them may make others difficult to understand. Secondly, I think we should compile and run the dashboard after translation to make sure that UI / UX is correct and reasonable.

Completely agree 👍

[shu-mutou]

My opinions are as follows:

• Localization is to use easily for endusers, and not to force using the words in original language.
• Different from sig-docs, we should also consider about UX for enduser.
  
  
  
  • consistency between English words and translated words
  
  
  • layout of view (sometimes translated words become too long)
  
  
  • beginer friendly
  
  
• Applying sig-docs's standards into current implements is not always good for everyusers.

So I had added README for ja team as follows.

• Terms used as proper nouns for resource names that consist general terms, such as service, and their combinations should be also translated.

[zehuaiWANG]

+1 I think my poinion of translation is basically the same as @shu-mutou .

[shu-mutou]

@feloy @seokho-son @hwdef @tanjunchen Could you let us know your opinion?

[feloy]

For my part, I tried to use the terms used in the translated UIs in the different clouds (GKE, AKS, EKS), so the user is not lost between public Cloud UIs and Vanilla Kubernetes dashboard

[shu-mutou]

@feloy Thank you for informations that public clouds also translate resource names. It may suggests direction of this discussion.

[zehuaiWANG]

Thanks for @feloy 's opinion, I think maybe the translated UI image can be pasted here for users to comment and see if there are any problem.

[seokho-son]

As a Korean contributor, my initial opinions regarding translation are as follow,

• Current status in each translations
  
  
  
  • terms for resources have been translated according to their Korean pronunciations. (this is guidance from the Korean l10n team of SIG-Docs)
  
  
  • all terms have been translated according to Korean glossary for K8s. Korean glossary is managed by discussions in the Korean l10n team meeting.
  
  
• They should be translated, or not.
  
  
  
  • In terms of l10n, I prefer to translate the terms. Because it is (local) user-friendly and the translated terms are familiar (as least for Korean).
  
  
  • If there are any UI/UX issues because of translation, I think it is possible not to translate those terms to provide consistency between English dashboard and localized dashboard.
  
  
• How to define the words untransatable.
  
  
  
  • I hope to share how we handle this in Korean l10n team of Sig-Docs.
    
    (1) we don't translate terms involved in commands that could be utilized by copy&paste for CLI
    
    (2) we don't translate camelCase terms.
    
    (3) Usually, we don't translate software or product name. (but if it is well-known name like linux, we discuss whether to translate or not)
  
  
• etc.
  
  
  
  • I can get opinions from K8s Korea user group as well.
  
  
  • should we align translations for all languages ?
  
  

[floreks]

IMHO we should not translate some Kubernetes specific names like the ones listed by @zehuaiWANG. In example polish translations would sound a bit ridiculous and most Kubernetes users would have no idea what are original names for them. Also, I would not want to have those words translated for some languages and not for the others. We should choose one path and be consistent across all translations.

Another thing is that we want feature parity with kubectl and for the user to be able to easily switch to cli in case he needs to use some features that are not available in the UI. If we'll translate everything, it will be harder.

[hwdef]

I agree with the list, and I think we should create a text to recording them,
If there is a new word later, we can add it to the text.

[feloy]

If the dashboard goal is to map the k8s resources directly, without trying to find an upper representation with more generic concepts, I agree that we should use the Resources names and not try to translate them.

In this case, it would be important to make clear to the user that these terms are Resources names.

[shu-mutou]

Actually, both opinions exist in Japan. Expertised users who use CLI usually and can describe docs tend not to translate. UI developers tend to translate considering UX for beginners, layouts, inconsistency between singlebyte and multibyte characters.

The main objective of UI might be to make dashboard for everyone to use k8s easily, I think.

We can't conclude immediately, so it might be good to consider in the UX working group.

[hwdef]

Suggest adding words

1. volume
2. token

[maciaszczykm]

I think we have more or less of agreement here. Let's close it for now and reopen if there will be anything to clarify.

[hwdef]

Suggest adding words

1. Workloads
2. Service Accounts
3. Custom Resource Definitions
4. Subjects