Improve installation language requirement descriptions and offline detection

@Sutharsan, I applied patch in #3 and getting below error when try to install fresh (no settings.php, no defualt/files/ and empty DB).

Thanks for the update @Sutharsan. I'm getting below error now (as I'm behind a proxy). it is better than #4. However, I'm just wondering why it doesn't say "Failed to connect the translation server", which is more appropriate to my problem. As I can visit http://ftp.drupal.org/ directly, "Check internet connectivity" might confuse user...

this manual testing, is probably more complicated than typical novice, so tagging medium

@Sutharsan, you are right. Seems I tested without the patch on #7. I just confirmed that it is working as expected. Sorry for the confusion.

I can confirm the translation unavailable scenario as well:

After select a language, if we try to change mind, it doesn't allow (until remove the .po file of selected language) as below screen. Just want to confirm that is working as per design.

Guess, we can RTBC, if you are OK with this test.

Updating screenshots in #10.

#1848490-42: Import translations automatically during installation 8. shows that is by design (or was at the time).

I think a separate issue should be opened to discuss that. There are a couple of use cases at odds there.

looks like manual testing is done. (updating tags)
Just a code review needed now.

#3: install-language-requirements-1912886-3.patch queued for re-testing.

Just re-testing... AFAIK, code looks fine to me.

#3: install-language-requirements-1912886-3.patch queued for re-testing.

#3: install-language-requirements-1912886-3.patch queued for re-testing.

#3: install-language-requirements-1912886-3.patch queued for re-testing.

#3: install-language-requirements-1912886-3.patch queued for re-testing.

Re-rolling...

Only skimmed this issue quickly (coming here from #1991298: Fatal error when installing Drupal on servers that don't have the cURL extension which may turn out to be relevant for it) but:

+        'description' => st('The installer requires to contact the translation server to download a translation file. Verify that your website can contact the translation server at <a href="!server_url">!server_url</a>. This fault may be caused by firewall or proxy settings.', array('!server_url' => $server_url)),
....
+          'description' => st('The %language translation file is not available at the translation server. <a href="!url">Choose a different language</a> or select English and translate your website later.', array('%language' => $language, '!url' => check_url($_SERVER['SCRIPT_NAME']))),

Why not add the "select English and translate your website later" text/link to the first message (and all others too)? That seems like a very important link, and (besides the back button) is the only way some people will get out of the hole they're in when they see this screen.

Also, the grammar here is wrong (both added via this patch and some of the existing messaging). Instead of "requires to contact" it should be something else... I think "failed to contact" would be fine here? But if "requires" is going to stay it should be something more like "requires a connection to" or "requires the ability to contact".

This patch needs to be re-rolled since the install.core.inc file has changed.

Re: comment #23, I would also recommend changing 'The installer requires to contact the translation server' to 'The installer failed to connect to the translation server'.

@Sutharsan - Name your interdiff ending in .txt, not .patch. That way it doesn't go through testbot :)

1912886-install-language-messages-26.patch still applies to HEAD as of today.

#26: 1912886-install-language-messages-26.patch queued for re-testing.

I've test installation without internet connection with patch #30 applied and worked as described.

Just one additional idea for a better user experience.

Because user needs to change the language to English anyway,
it needs to detect internet connection before it suggest language to install and default installation language needs to be English
in case
1. the server can not download browser language
and
2. the distribution doesn't include language file with it.

@Sutharsan, I agree with you re suggested function on contacting the translation with prior consent of user.

Then, the patch just need to pass the simple test.

38: 1912886-install-language-messages-38.patch queued for re-testing.

Trying to reroll.

needs a beta evaluation (especially since this is a normal task). added instructions to the issue summary.

This is an installer usability / user experience issue and as such should be among prioritized changes as per https://www.drupal.org/contribute/core/beta-changes (for that issue summary update).

@develCuy: are you working on this one?

Removed SprintWeekend2015Queue by mistake.

I am working to reroll

Here reroll

Let's make sure we have tests.

@gábor-hojtsy

I am revised manually and works correctly.

Test this patch in the following situations:

• Drupal 8 located on a server behind a firewall which blocks HTTP access to ftp.drupal.org
• Drupal 8 located on a server behind a proxy server which blocks HTTP access to ftp.drupal.org
• Drupal 8 located on a (localhost) server with no connection to internet
• Drupal 8 located on a (localhost) server with an unreliable internet connection. E.g. 3G while traveling
• Install with a non-existing language code in the url. E.g. core/install.php?langcode=xyz
• And finally ;) Drupal 8 located on a (localhost) server a normal internet connection installing in a regular language.

Here some capture.

We (@jlbellido, @fran-seva) are trying do some test but we do not know if it is possible.

Attached captures, sorry

@Gabor I need more info to implement the tests :S

Using drupal 8.0.6 it also gives the error

The translation server is offline.

The true error is:
cURL error 60: SSL certificate problem: unable to get local issuer certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

What I find strange is that the url that is checked is:
http://ftp.drupal.org/files/translations/8.x/drupal/drupal-8.0.6.nl.po

However when I check the GuzzleHttp output it tells me it calls:
https://ftp.drupal.org/files/translations/8.x/drupal/drupal-8.0.x.nl.po

This can pose problems for lots of people working on a webserver that doesn't have a certificate installed since there is no error and no easy way to fix it.

I created an fix that forces using http instead of https to make sure people will get past the first installation screen, since drupal is allready trying to call the http url I recon there is no problem with the fix?

Okay Apparently coding of the patch got messed up somehow, so we will try again but now an UTF-8 file.

another attempt to get the patch right for the test.
Still regarding issue for comment #60

another attempt to get the patch right for the test (got to love this patch system)
Still regarding issue for comment #60

See comment #60

The patch looks good to me and applies cleanly on Drupal 8.2.x

Sorry @Kifah Meeran, I disagree that this is RTBC. The patch we should use is in #52 and if you have tried it and it worked, then we need to add tests as per #54.

@redsd, all your patches from #60 have one line of code change and pretty much same. Are you trying to do something entirely different from what we got so far in #52?