[meta] Replace Drupal in UI text with the name of the distribution

Adding some notes to this.

Separating this into groups of modules and making explicit Novice tasks.

Novice issue reserved for the Mentored Contribution during the Contribution Day at Europe2020. After the 11th December 2020, this issue returns to being open to all. Thanks

Fix list of child issues.

Proposed child issue title is way too long. Streamlining suggestion.

Added child issue for: views, views_ui

Added child issue #3187895: No "Drupal" in UI text -- migrate, migrate_drupal, migrate_drupal_ui

Here is a grep command that will find occurrences of "drupal" that are likely to need replacing:

egrep -i -e "'[^']*[^/\]drupal[^/\]" -e '"[^"]*[^/\]drupal[^/\]' `find . \( -type d -name tests \) -prune -o -type f -print` | grep -i --color drupal

This aims to find the word "drupal" inside a string enclosed by single or double quotes. This isn't perfect by any means (occurrences of "drupal" following a quoted string will also be reported, for example), but hopefully everything that might need to be changed will be shown. (I'm assuming that we're not interested in anything that's part of testing.)

Thanks, that looks very helpful! It does give some false positives, but better than than missing some things we do need to change. Let's add this to the issue summary.

Also, thanks for making some child issues!

Indeed we do not want to worry about things in tests, although if we change UI text and that text is being tested in a test, we'll have to do a corresponding update in the test. But we'll know that if a patch is uploaded, because it will fail the test.

Uh ho, can't use a code tag within a code tag! Fixing summary.

Closed #98905: Remove the word 'Drupal' from interface as a duplicate, adding credit. That issue referenced #182991: Standardize on "internal path" instead of "Drupal path" or "system path" which I am adding as a reference here as well because it also removes Drupal from the user facing text, and has a patch.

Copying over my comment from #2143615: No "Drupal" in UI text -- config_translation, content_translation, locale, language, and translation server parts of installer since this is probably the issue to have that discussion (or a policy, no patch spin-off).

This issue was opened in 2013 and it feels a bit like things have moved on since then. IMO we need to rethink the basis for the overall change.

- In 2013, if you installed a distribution, Drupal core would change very little while the distribution might change a lot - until you got to a new major Drupal version which could be years away. Drupal core now has minor releases every six months, and the string changes here obfuscate this a bit. We're really talking about Drupal version and that is meaningful information, not 'site version' which is not really a concept.

For example here:

+++ b/core/modules/locale/locale.install
@@ -172,7 +172,7 @@ function locale_schema() {
         'default' => 'none',
-        'description' => 'Version of Drupal where the location was found.',
+        'description' => 'Version of site where the location was found.',
       ],

- If we replaced Drupal with $distribution_name instead of 'site' that might help, but the version of a distribution is not going to match the Drupal core version at all, so it would still be misleading.

- Also I wonder how many distributions actually try to suppress the fact they're built on Drupal?

+++ b/core/modules/locale/locale.module
@@ -155,9 +155,9 @@ function locale_help($route_name, RouteMatchInterface $route_match) {
       $output .= '<dl>';
       $output .= '<dt>' . t('Importing translation files') . '</dt>';
-      $output .= '<dd>' . t('Translation files with translated interface text are imported automatically when languages are added on the <a href=":languages">Languages</a> page, or when modules or themes are enabled. On the <a href=":locale-settings">Interface translation settings</a> page, the <em>Translation source</em> can be restricted to local files only, or to include the <a href=":server">Drupal translation server</a>. Although modules and themes may not be fully translated in all languages, new translations become available frequently. You can specify whether and how often to check for translation file updates and whether to overwrite existing translations on the <a href=":locale-settings">Interface translation settings</a> page. You can also manually import a translation file on the <a href=":import">Interface translation import</a> page.', [':import' => Url::fromRoute('locale.translate_import')->toString(), ':locale-settings' => Url::fromRoute('locale.settings')->toString(), ':languages' => Url::fromRoute('entity.configurable_language.collection')->toString(), ':server' => 'https://localize.drupal.org']) . '</dd>';
+      $output .= '<dd>' . t('Translation files with translated interface text are imported automatically when languages are added on the <a href=":languages">Languages</a> page, or when modules or themes are enabled. On the <a href=":locale-settings">Interface translation settings</a> page, the <em>Translation source</em> can be restricted to local files only, or to include the <a href=":server">site translation server</a>. Although modules and themes may not be fully translated in all languages, new translations become available frequently. You can specify whether and how often to check for translation file updates and whether to overwrite existing translations on the <a href=":locale-settings">Interface translation settings</a> page. You can also manually import a translation file on the <a href=":import">Interface translation import</a> page.', [':import' => Url::fromRoute('locale.translate_import')->toString(), ':locale-settings' => Url::fromRoute('locale.settings')->toString(), ':languages' => Url::fromRoute('entity.configurable_language.collection')->toString(), ':server' => 'https://localize.drupal.org']) . '</dd>';
   

On top of that, this link goes to localize.drupal.org, so changing the string name doesn't actually help to obfuscate the fact we're running Drupal at all.

[duplicate comment]

Splitting up cleanups like these by modules is explicitly prohibited by the core issue scope guidelines. Issues should be subdivided by the pattern or type of usage, not a module or set of modules.

Please merge these into a single patch; there aren't that many. If unmanageable when combined and split up, the scoping should be based around whether it's in YAML or a t() call or whatever.

I closed the child issues as duplicates. Adding credits for those issues' participants according to core credit guidelines. Thanks!

Marking for an IS update to remove the incorrect scoping recommendations.

I guess the core issue scope guidelines may have changed since this issue was created in November 2013. It seems I wasted my time creating those child issues a couple of years ago!

@dabley, yep, around 2014 or 2015 is when we learned hard lessons about the bad things that happen when we scope things by module. Sorry about the wasted time! But hopefully we can merge the three issues together here pretty easily.

@xjm, yes I'm sure it makes sense. It was all good practice for me as a beginner with Drupal.