Config translation - access denied

In PHP code I'm using:

$config = \Drupal::config('google_analytics.settings');
$id = $config->get('account');

Do I need to prefix the variable like google_analytics.settings.account? I thought that context comes from base_route_name or google_analytics.settings: (first line). The structure of the file is really unclear to me. No idea why first line and base_route_name are the same in all files I've found. And there are no docs about this yet.

google_analytics.settings:
  title: 'Google Analytics'
  base_route_name: google_analytics.settings
  names:
    - account

For me it looks like the translation tab does not exists and is causing the access denied.

You mean it should be like this??? I should change my route name than...

google_analytics.settings_form:
  title: 'Google Analytics'
  base_route_name: google_analytics.settings_form
  names:
    - google_analytics.settings

I thought the Names are all keys that should be translatable as not everything in a string should be a translatable string. Additional to this - how can I prevent l.d.o from making my "translatable" configuration strings translatable on d.o? Well, some of the settings should be configurable per language, but not "translatable" the classic way like t() strings.

Is there any documentation about the .config_translation.yml files? It's very confusing to me what is in the API file. Looking for something like:

[this is the route name used in "module.menu_links.yml"]:
  title: 'The title used for the above route name in "module.menu_links.yml" or is this just the button name shown on config translation page?'
  base_route_name: [this is the route name used in module.menu_links.yml, but why the heck the same like above? e.g. mymodule.admin_form]
  names:
    - [the config object name like "mymodule.settings"]

Please correct if something is wrong... and let's follow up with a patch for the API file for clarification.

Huh, yeah that is all 1000 times better than D7, but I do not think it is a good idea to push all my settings to l.d.o and I really think this might end with horrible troubles as people may start translating settings that are just site specific and not language specific. I think we need something to tell l.d.o to not extract the strings. Otherwise... lots and lots of new troubles...

Something like:

    account:
      type: string
      label: 'Web Property ID'
      translatable: true
      potx: false

Changed all route names, but still get access denied. Pressed several times clear cache and then also tried uninstalling and re-installing GA. No success.

Now, after adding translatable: true I get a form.

[schema]

  account:
      type: string
      label: 'Web Property ID'
      translatable: true

I'm finally confused... will POTX extract the default setting value of translatables from install/google_analytics.yml and import them to l.d.o for translation or not?

Let's say something I really do not like to see on l.d.o would be visibility.pages value if I enable translatable:

visibility:
  pages: "admin\nadmin/*\nbatch\nnode/add*\nnode/*/*\nuser/*/*"

In previous versions of GA I have added account to variables module and allowed translation of this. This makes sense if you run one UA codes per site language. I believe there are more settings that may be useful.

And this code change is something core translation module should add automatically I think. Otherwise we need to teach every developer who enable a translatable strings to not forget adding a module_local_task.yml to the module.

Well, I may need to use what exists. I strongly believe we need per language configurations like we had a need for them in past. What has been implemented already may not the intended use case, but it looks like a working solution to me. I guess we need a new issue to close the lack of feature and I opened #2275865: Per language settings (vs translated settings) are not directly supported for this. However I think we have everything in place already, we only need to tell POTX not to extract these translatable strings to l.d.o. This extractor is not yet done as I know from a different case.

I'm closing this case for now as your support helped me getting the issue resolved. I opened some individual issues for the things I learned here.

or should we keep this case open here and change the misleading access denied message to a more useful message?