English-specific links to php.net shouldn't be used in non-translatable strings

This one is just plain wrong:

+++ b/core/lib/Drupal/Component/Datetime/DateTimePlus.php
@@ -280,7 +280,7 @@ public static function createFromFormat($format, $time, $timezone = NULL, $setti
    *   parameter and the current timezone are ignored when the $time parameter
    *   either is a UNIX timestamp (e.g. @946684800) or specifies a timezone
    *   (e.g. 2010-01-28T15:00:00+02:00).
-   *   @see http://php.net/manual/en/datetime.construct.php
+   *   @see http://php.net/manual/datetime.construct.php
    * @param array $settings
    *   (optional) Keyed array of settings. Defaults to empty array.
    *   - langcode: (optional) String two letter language code used to control

We don't put @see in the middle of an @param. It should just say "See " not "@see".

That error is repeated here:

+++ b/core/lib/Drupal/Core/Datetime/DrupalDateTime.php
@@ -38,7 +38,7 @@ class DrupalDateTime extends DateTimePlus {
    *   timezone are ignored when the $time parameter either is a UNIX timestamp
    *   (e.g. @946684800) or specifies a timezone
    *   (e.g. 2010-01-28T15:00:00+02:00).
-   *   @see http://php.net/manual/en/datetime.construct.php
+   *   @see http://php.net/manual/datetime.construct.php
    * @param array $settings
    *   - validate_format: (optional) Boolean choice to validate the
    *     created date using the input format. The format used in

I don't know if you want to fix those problems here or in a separate issue? The patch isn't very large...

Anyway, if you want to make a separate issue for those @see violations, then this patch is fine. I tested all the URLs that are fixed, and they are all going to their intended locations. And there are no translated strings being changed. So, if you want to put the @see thing in its own issue (there may be more instances of it), then this patch is RTBC. Otherwise, it is Needs Work for changing @see to See.

For reference... Here are the standards on @see:
https://www.drupal.org/docs/develop/coding-standards/api-documentation-a...
This part of the standards doesn't exactly say "don't put this into another part of the documentation" explicitly, but they do say that the @see references are collected into their own See Also section. Which implies they are not part of the text of something else, like a @param.

Also note the order of sections in doc blocks:
https://www.drupal.org/docs/develop/coding-standards/api-documentation-a...
@see is near the end, and as stated there, each tag listed goes in its own section.

We should definitely have a Coder sniff to sniff the order of docs sections, which apparently we don't already have or else it isn't being enforced... Anyway that is probably a separate issue, so I'm marking this as RTBC.

Follow up is fine for the @see

@vaplas -- @see means "Add this to the See Also section at the end of the documentation". Here, it is being used as if it means "Replace @see with the words "See also" and leave it embedded in this text". Because of what @see does, we structure the documentation by putting all the @see lines together at the end of the documentation, so that the doc block in the code reads pretty similarly to what you see on api.drupal.org when it's parsed out.

Regarding the 4 other php.net/.../en things, these are all inside t() calls. Meaning they are in translated strings. This is a fairly minor problem, and probably not worth changing translated strings over (see parent issue for discussion on that).

Regarding @see in // comments, I'm not as concerned... They aren't parsed/displayed as Function/Class/Etc. documentation, so they don't need to be quite as formalized. @see seems clear enough (and clarity should be the goal of // comments, explaining why the code is how it is). But inside @param or @return or etc., @see is kind of problematic for parsing.

Needs to go into 8.5.x first, but doesn't apply.

Re rolled the patch to 8.5.x

Thanks!

Committed as 32cc90b and pushed to 8.5.x.

As per https://www.drupal.org/core/release-cycle-overview#current-development-c... 8.4 is in 'critical fixes only', so this can't be backported to 8.4