Document that locale + config translation integration treats string uniqueness the same way as locale itself

Not sure I understand the question. The locale + config translation integration is built for shipped config, that is all the config that was part of projects when you installed them. The integration exposes all source strings in those configs in locale on the regular "built-in user interface" translation UI so you can translate user roles, formats, content types, etc. The integration also allows localize.drupal.org to feed translations to the site. Uniqueness for these strings are managed the same way as for strings in t(). So long as there is no context provided, they are global. So if you translate 'Drupal' on localize.drupal.org, that translation will apply too all occurances of that string in default configuration too where no explicit context was provided to make the string more unique. That also means that if you locally update the translation to 'Drupal', all config translations which had that source string will be updated with the new translation. If you update one of the config translations changing the translation there, it will feed back to locale. (It seems to be a bug that in this case all other config that may have the same source string are not updated, but that would be consistent with the behavior for the other cases).

Does that answer the question?

Opened #2460837: When updating a config translation, locale integration does not update other affected config translations for that bug BTW.

So strings with t(), *.links.yml, Drupal.t(), default config strings, TWIG, routing.yml, etc. are unique per string. Contexts may be provided for each:

// PHP
t('May', array(), array('context' => 'Long month name');
format_plural($count, '1 something', '@count somethings', array(), array('context' => 'My context'));

// JS
Drupal.t('May', {}, {'context': 'Long month name'}
Drupal.formatPlural(count, '1 something', '@count somethings', {}, {'context': 'My context'});

// *links.yml
title: 'May'
title_context: 'Long month name'

// Config schema (assigns the context to the data when parsed)
date_format:
  type: string
  label: 'PHP date format'
  translatable: true
  translation context: 'PHP date format'

// Edit: note that 'PHP date format' it itself a translatable string that cannot get a context

// routing.yml
something:
  pattern: '/something'
  defaults:
    _title: 'May'
    _title_context: 'Long month name'

// TWIG
{% trans with {'context': 'Long month name'} %}
  May
{% endtrans %}

There may be others I am missing, these came to mind quickly. The contexts would make them unique only in that context. So if someone translates 'May' it would not show up in the given TWIG, routing, etc. situations unless it was done within the 'Long month name' context. (String context is displayed on the interface translation UI, its passed over in the .po files and displayed on localize.drupal.org too with each string).

Hope this helps @jhodgdon.

Patch looks good :) Some notes:

1. +++ b/core/modules/system/core.api.php
   @@ -236,21 +236,27 @@
   + * types label, text, and data_format in configuration schema are translatable;
   

   date_format

2. +++ b/core/modules/system/language.api.php
   @@ -77,12 +77,74 @@
   + * buttons on them, and they all would have t('Submit') in their code. The
   

   We don't actually suggest to use the button label "Submit" on submit buttons for UX reasons. We use "Save configuration" for example. The most widespread example in earlier Drupal versions at least was "Operations", that is one of the most widely used source strings. Not suggesting you completely change up the example, but maybe using "Save" or "Save configuration" would be better to follow UX guidelines.

+1: Add that labels defined in config schema themselves are also translatable. They cannot provide a context though for the translation of themselves.

Looks good to me! Documents the status quo well. Thanks for your help with this!

Yay, thanks!