Consider this sequence of events: you try to install a language pack that was already installed (you perhaps did a re-install of SharePoint in the meantime). The language pack installation fails with a helpful message in whatever language you are installing. You go to your web site; gone - 503 error. You go to Central Administration; gone - 503 error. Time to start worrying.
You look at your ULS logs. Nothing. You look in the Windows event log. Nothing. You run IISRESET. No change. You open IIS Manager and look at your web applications. All running. Time to start panicking.
What this means is that the application pools have been stopped. As far as I can tell the cause of this is that they have been stopped by the installation process, which then fails before it can re-start them. Of course there may be other circumstances that produce the same effect, but this is the one that I am aware of.
If you go to Internet Information Server (IIS) Manager and click on Application Pools, you will probably see that all the SharePoint application pools have been stopped. This is likely to include the web applications, central administration, and critical web services such as STS. If you start them (right-click then Start) this should solve the problem, and you'll be back in business.
If you can't re-start the application pools, check that the user or permissions haven't changed somehow (right-click then Advanced Settings...). If the password has changed you can select the user identity ("..." button) and use the Set button to update it.
Somebody pointed out to me that another possible cause is if a web application started out as a 32-bit ASP.NET application, and subsequently got converted (upgraded) to a SharePoint 2010 web application. In this case you will see that the application pool has the "Enable 32-Bit Applications" property set to true, which is incompatible with SharePoint 2010. Setting this property to false shoud solve the problem.