Follow-up: First installer page has initially needless description for how translations are handled

tag

So do we want the submit button jump around based on the option selected? Is that good?

Also the text is displayed based on prior "big brother" concerns around update module. In this case as well, the server *could* collect this information (it does not currently do), and we wanted to let people know and be able to opt out. In this implementation suggestion it looks like people need to figure this out themselves. Because the language is preselected, on the foreign language case, the text will be displayed (and you would need to guess how to opt out). Do we assume people just know English is the opt-out?

@yoroy: I mean it jumps around because based on what interaction you use to pick the language, the moving of the button down visually may be problematic. Eg. if you are too quick with your mouse. Or you just click where you seen it and the button is not there anymore, so you click the "Drupal Translation Website" link accidentally. That is what I meant by jumping around.

So I guess your suggestion is now up to "Translations will be downloaded from the Drupal Translations Website. If you do not want this, select English." Or something else? :)

@yoroy: reality is that you are not really the person picking the language, if you ever configured your browser (or in case of a Mac your OS) to know your preferred language, then we get that info, and pick the language based on that. So in my case for example, I always get Hungarian preselected. So I'm already always getting a language from where it makes sense to "reset" sometimes (to English that is).

So the two sentences may very well be relevant already when the screen is displayed. I agree we may hide the text by default if English was selected.

I'll ask @borisbaldinger to look at this if I can find him.

It is not that expert, eg. if you installed your Mac in a foreign language which is not very atipical right(?) then you get that info from the browser on the server :)

It is not that expert, eg. if you installed your Mac in a foreign language which is not very atipical right(?) then you get that info from the browser on the server :)

Yeah that only changes what may usually display by default, yes.

You can do "Translations (other than english)....."

I really applaud this idea though :) I never realised this text was like this, until it was in core.

Just to be sure that I understand right, the task is:

1. Change the text in install.core.inc to "Translations will be downloaded from the Drupal Translation website. If you do not want this, select English."
2. Provide a small JavaScript (jQuery) file (in Seven theme) which removes the text when English language option is selected

Am I right?

@thamas: yes and yes :)

Here we go!

I would try to add an id to the text element and use #states for hiding/showing (meaning please try doing that instead of a custom JS file :).

Other than that and for your next js patches ;) the code doesn't conform to code standards, missing space between function and ( in the declaration, the if missing some spacing, you're using both " and ' for strings, use only '. use .on('change') to bind events, not the alias, it'd use $(this).toggle($(this).val() === "en") instead of an else/if and when a variable is actually a jQuery object we add $ in front of it, so help becomes $help and finally to call events use .trigger('change'), not the alias.
Also the script is added on all pages, you should create a new library, an #attach it only on the select element from the first page.

As you may find it I'm (still!) not a JS guy… :)

I added the script 'cause in #17 Gábor confirmed this method. And I did not want to give an id to the text 'cause that is the only p tag and I do not think there will be to much other p -- on that page. ;)

Nevertheless thanks for the review and especially for your suggestions and guidance!

No worries, but either way, it's still need work :)

Here is a new patch without added JS file and using #states.

If I understand right https://api.drupal.org/api/drupal/core!includes!common.inc/function/drup... and https://api.drupal.org/api/examples/form_example!form_example_states.inc... than it should work.

But unfortunatelly it does not work. :(

Suggestions welcome!

(Hm, I do not know how did I set status to 'needs review' in #21. I did not do that (manually). Maybe some browser cacheing…)

Yeah because we're using #markup here some light workaround is needed. Since we're using #markup it doesn't go through the usual stuff for render arrays, and even using #type html_tag doesn't work because apparently that gets converted to #markup early on, before the #attributes can be added by drupal_process_states().

All in all, just added a container that holds the #states information and gets shown/hidden when needed.

About the selector you used, I changed back to select instead of using jQuery stuff since we're trying to remove all jQuery sepcific selectors and replacing them with proper CSS3 selectors.

But to be fair, that issue might have been a bit tricky to handle given #markup and #states subtleties.

Not suprising: it works. :)

Thanks for the help nod_!

@yoroy: thanks, lets move back to #1337628: Enhance language select form with textbox and other tools then? :)

So I think this patch is fine to commit, because based on the original text in comment #1, this is a clear improvement.

However.

The text as it is is very insufficient for explaining to me why I might "do not want" to download translations. And there are many reasons I might not want to. I might be concerned about how localize.drupal.org uses my site data (this needs to be a blurb in https://drupal.org/privacy). I might be concerned about the fact that there's no central oversight of these community-provided translations, so the updated strings could literally be anything, including changing "Register an account" to "Go away, bozo!" or even "<script>alert('mwahahahaha');</script>" This information needs to live somewhere, most likely semi-prominently on localize.drupal.org, which is already linked to from this message. Right now, the only link that sounds close on the l.d.o home page is "how localize.drupal.org works" (http://drupal.org/translators) which is more about how contributors work with localize.drupal.org, not how users are impacted by it.

So, long story short, this looks good since this problem exists with the current text, but we need a (critical? major?) follow-up to make sure users have something they can read on the l.d.o home page if they have questions about why they may wish to opt out.

Committed and pushed to 8.x. Thanks!

Yay, thanks!

Simplification of the #states code since #1589176: Follow-up: Use data-* to store #states api informations got in.

Looks good!

RTBC +1, tested manually, works great!

We had #30 before D7 upgrade, didn't we? Glad to have it back! :)

Can we change the label in the language selection dropdown list and in the "If you do not want this, select English" comment to "American English" (or "English (American)" might be better). Hopefully there will be a British English translation and my browser will pick that as the default. Otherwise it is going to be a bit confusing for people who have selected non-American variants of English as their default languages.

@StuartJNCC: first the language list has "English" (as-is) without qualification as to whether it is British or American. Second, Drupal's English can hardly be called American. I think there are so many nationalities writing the text, that saying it would be American English is probably a big oversimplification.

Gábor: I do understand, but the sites I run are aimed at amateur naturalists and this audience tends to have a high average age - many are retired people. They regard "color", "organize", etc. as misspellings (and aren't slow about pointing them out)! I am hoping Drupal 8 will have a GB "translation" to "correct" this sort of stuff. I am even willing to do the necessary translations. So, I would just like to make sure it is a smooth experience.

@StuartJNCC: you can help with that at https://localize.drupal.org/translate/languages/en-gb, this language is not yet listed in core because as you can see the last version where translations were entered was for Drupal 5.

@webchick: re #28, your point was not forgotten. Created https://localize.drupal.org/privacy-and-security and in review by the security team. I think that can be considered closing that not even opened issue :) I put it into the main nav on localize.drupal.org in the top nav.

...adding parent issue and attempting to fix inline image in issue summary.

30: core-js-installer-states-2033959-35.patch queued for re-testing.

Committed and pushed the follow-up in #30, and agreed that with the creation of https://localize.drupal.org/privacy-and-security we can probably call this fixed. Yay. :)