There is not a need to translate the built-in, system language.

Thanks for raising this issue @likin. So there are two issues here (if I'm not wrong):

1. Hide translation when site is in one language.
2. Hide default language when more than one language enabled.

Here is the patch for #1. I'm not very sure about #2 as it would be necessary to keep there for UX. But lets wait for @gabor's thought.

Nonononono! If you are a single language site, your config that shipped with core would be in the built in English still! Even if you are a Spanish only site. Then we need the UI to let us translate from English to Spanish the things that were shipped with core and your modules and themes. Clear?

However, it is true that of the group language is not English, and the site is not multilingual, THAT combination may indeed not bother with a translation tab. So for example the site information settings on a single language site. There is maybe an argument to be made there that the tab serves an educational purpose Rollo of what could happen though. Say you are a Greek only site and you have 20 views. Half originally shipped, half you created. Now only the first half would have a translation operation then and you may interpret this very well as a bug, unless you notice the pattern why.

For example if you look at core content translation, it does something similar. If you have translatability enabled on an entity type, it will have translation tabs on things even if no field is marked translatable. Then that screen educates people to enable field translatability.

I think for config it equally is an interesting educational thing, but it may/will get annoying after a while.

Tagging.

I agree with Gábor that this doesn't make sense due to config that is shipped in English. I suppose there could be a setting to hide the translation option on config that is in the default language. They would need to enable this for the translation option to go away for those. But, I think this would likely go unused and it seems preferable to have the consistency of having the translation option for all config rather than only on the English config.

Perhaps some single-language site maintainers should chime in on this one?

I'm a bit confused about the suggestion.

I think it would help to embed the screenshots (I'm a fan of embedding, and use dreditor to make that easy to do).
And also to include screenshots of the suggestion.

I'll have a go at that.

Single non-English site

Is the idea that the translate tab is not needed because the edit tab would be editing in the one language (russian)?
Would the builder/maintainer of a single language (russian) site ever want to edit the default English config?
How will this workflow be different when we are including translations of shipped config?
Will that edit be editing English?
I need to try it.

Few language site

why remove the edit for english here?

I'm thinking we want to keep it...
I'm not sure how editing the source language (English), is different than editing the main navigation menu.
if the UI for translating includes an option to select the source (like content translation does) .. I'm not sure how that changes things.

I have a feeling we want a way to edit the "source", either from the translations English edit, or from the Edit tab, so that when adding another language, and translating to that new one, we are translating from the correct (perhaps customized) source.

Let's get a screenshot of the edit tabs for those situations so we can see.
Contributor task doc for screenshots might be helpful: https://drupal.org/node/1859584

uh, I dont know why embedding didn't work.. trying this.

Yeah... some screenshots of what you are envisioning would be good. I'll mark as postponed to get more input from @likin.

Yeah, the edit will not always be for the built-in language. For shipped configuration it is. As soon as you create your own menus, those will be created in your language, not in English. So different menus can be in different source languages. Part of the reason to include the original language in this table is to educate users about the source language for the config being translated. As to why it has a link to edit, well, we can avoid putting a link on the original language, but then people need to independently figure out to go out of the translation page to edit the original. On the content translation screen, we also have the original editing interface linked in along with the translation editing links. So if you are on this screen, you get an overview of all languages this config is available in, and editing links for all of them.

Yeah, compare these:

1.
- go create a node of a type that is configured to be translatable
- translate it to a couple languages
- view the translation tab on the node
- it will have links to all language versions, original and translations

2.
- go create a menu
- translate it to a couple languages
- view the translation tab on the menu
- it will have links to all language versions, original and translations

The two behave the same. As for nodes, there are no shipped nodes coming with the system. There are shipped menus, so some menus will already be present and you did not create them. I don't think those should behave differently though and should apply the same pattern that (1) and (2) do here. Helpful explanation?

Ok now the question is if we believe now that this closes the issue since it just follows an existing pattern :)

I vote yes :)