About the Code

PHP is incredibly beginner friendly and the official documentation so instructive that writing the backend code really did not hurt. But web programming is weird in that HTTP is static - somewhat dead once the html is loaded - but the way people use it is highly dynamic and interactive. It honestly took me a while to accept that there simply is no loop waiting for your input to change the content on the go as you want it. One solution is to reload the whole page adding what the user requested - the first version was a form that posted all you need for the dictionary search to the same current page, to display the result after a complete refresh. That was actually not too bad, browers and internet connections are so fast the time loss could not possibly slow down your work significantly. But blackouts just feel so bad, like a section of a movie where a cut for a special effect is perceptible. And conceptually it's just crazy - for Android the equivalent would be putting the entire logic in OnCreate and rebooting the whole app after each and every user submission.

Enter Javascript/JQuery to implement AJAX. People hate plain Javascript because of its verbosity, but compared to what they make you write in Android I suspect that concern is usually exaggerated. What really matters though is that if you hardcode every bit and piece in plain Javascript there are so many things you can do wrong, and working with simple text editors (no light bulbs making you correct suggestions on hover) it just really slows you down a lot. With JQuery, you cannot get those details wrong because they are hidden from you in the first place. By the way I decided to use POST because the appended GET URLs would appear in logfiles including what you were looking up. Nobody cares about a single search but a long sequence of searches, when you are translating something super confidential for example, could be an issue, but maybe I'm being paranoid. Anyway switching from POST to GET should be as easy as deleting the type: "post" and running a search/replace ($_POST -> $_GET) wherever you access the array. And that is just way better than plain Javascript.

Below the amazingly concise script that brings the dead page to life.

$(document).ready(function(){
   $("#form").submit(function(){
   //collect your variables like that:
   var variable = $("#someId").val();
   $("#resetButton").html('');//display waiting animation instead of reset button
   $.ajax({
     url : "YourBackendlogicScript.php", //what you echo over there will be your .html(data) in success
     type: "post",//default is get, post you have to specify
     data: {//this puts each item in $_POST like so
       variable : variable;
     },
   success: function(data){
     $("#resetButton").html("X");//switch button back because job is done
     $("#IDofElementWhereYouShowResult").html(data);//In my case plain text, nothing fancy needed
     }
   });
   return false;
  });
});

This callback subsititutes the recurring page reloads. The downside is that the page does not reload, so whatever you want to modify to make state persist has to happen somewhere else. I understand that from Javascript mode you cannot simply reassign another value to $_COOKIE and that is a headache. So although I do not even want the data, I now limit $_COOKIE to a numeric ID (set when page is loaded) and store that ID and the session variables (languages selected, search method etc.) in an extra table of the dictionary database. That doesn't matter now because there are hardly any users, but should there ever be millions I feel that storage should actually be paid for by users themselves on their own machines. In other words it's irrelevant. To not affect performance during lookups, the place to execute the cookie update (and some maintenance like deleting dead rows and optimize) would naturally be     $(window).("beforeunload", function(){ etc.... But that doesn't seem to work in Safari because they don't want you to see those "STOP YOUR COMPUTER HAS A VIRUS CALL THIS NUMBER" messages when you close. They recommend .pagehide instead but that also failed on my phone, so now each change in the settings fires an asynchronous call to update the database, wasteful but at least the time is not added to the lookup time as such. And not to forget: using https you should set the secure flag of your cookie to true.

Other important points some beginner tutorials might miss or underemphasize: when first passing user input from your html frontend to the php backend, use type "htmlspecialchars" in your php to avoid script injections there. Then, when your php uses that input for sql queries etc., only use prepared statements, where whatever input the user controls is just a "?" that you fill in later, to avoid sql injections there. And coming back from the php, do not just echo whatever the user typed into your html, because that would amount to another opportunity for script injections.