Replace user facing strings that use drupal.org as example of an external url.

For me it doesn't make sense to have this configurable but at least I changed the url's to example.com.

I agree that making it configurable is overkill. Using example.com is inline with general web standards, this makes sense to me.

+++ b/core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php
@@ -142,7 +142,7 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
+      $element['uri']['#description'] = $this->t('This can be an internal Drupal path such as %add-node or an external URL such as %url. Enter %front to link to the front page.', array('%front' => '<front>', '%add-node' => 'node/add', '%url' => 'http://example.com'));

So if the aim is to make this comply with the interface standard of not being identifiable as Drupal then This can be an internal Drupal path is not going to help :)

I guess one could argue it is out-of-scope but we are changing this line to remove drupal so I think not.

Changes mentioned in #3

Heh, nice catch @alexpott!
Yes, I think "Drupal" does not really give much additional value in that line.

UI strings are not yet frozen. Committed 685470f and pushed to 8.0.x. Thanks!

[edit]

oops. removed comment that is not relevant.

It's worth backporting this, I think (at least the part that doesn't involve breaking translations - it's probably not worth breaking translations for something like this).

Here it is for Drupal 7.

That patch is breaking translations though - per above I think this is really only worth changing in cases where it's part of the substitution (not part of the translatable string), especially since there's no actual bug here.

Or if there really is only that one case and we don't like the idea of "%drupal" referring to example.com (not that anyone would care in practice) we could just close this instead :)

@David_Rothstein I personally also think that most people don't really care about it. But some big companies and government agencies prefer to obscure the platform being used. Due to this reason, to improve Drupal's acceptance among these companies, the coding standard is to use example.com: https://www.drupal.org/coding-standards#example

For the same reason, the word "Drupal" got removed from that string.

About translations, this patch does not break the translation system. The reason you may not see a translated string is because the original string has changed. Every time a string is changed or a new one is added it has to be translated. This is the normal behavior.

Yet this is a minor patch, it is still a valid patch even with the translated URL, IMHO.

About translations, this patch does not break the translation system. The reason you may not see a translated string is because the original string has changed. Every time a string is changed or a new one is added it has to be translated. This is the normal behavior.

Yes, that is what I meant by "breaking translations" :) Sorry for the confusion.

Since these are admin-facing strings I guess we technically can break them even though this isn't a bugfix (see https://www.drupal.org/node/1527558) although not really sure if it's a good tradeoff to do that. People who need to remove "Drupal" from the UI have other methods to do that, and (I think?) many strings besides these they need to override.

By "not that anyone would care in practice" I was referring specifically to the idea of having %drupal point to example.com (not the overall goal of this issue), as a means of replacing the URL in that one case without breaking the translation... I still think that's worth considering, although it's true that there's another "Drupal" in the same string that would be nice to remove.

@alexpott this patch seems good to be applied to 7 too

The #16 commit was just an automated message due to the creation of the 8.1.x branch (it was committed to Drupal 8 a long time ago for 8.0.x).

I think I'm willing to commit this to Drupal 7, but only if we go ahead with #2598382: [policy] Adopt a 6-month feature release schedule for Drupal 7 (similar to Drupal 8) and use pseudo-semantic versioning. Those releases would be a window where bigger changes are acceptable and where people will be looking out for them, so I think that makes it more reasonable to do non-bugfix translation changes then too.

So I'm going to leave this RTBC but not commit it now - possibly for a release on April 20 instead.

Alright, it's likely enough that we're going to go ahead with the above, so let's bend the rules a bit and get this in.

Committed to 7.x - thanks!

Changing tags since the release that includes this will probably be labeled Drupal 7.50 to indicate it contains some big changes.