Installers for available Celtic language localisation packages are put in a structured data share on a domain server. This share is made accessible to domain computer accounts only. Installer file names are left as Microsoft intended.
A Group Policy Object is used to apply a localisation startup script (provided later in this article) to the domain's workstations.
This script finds out what operating system it is being run on. It installs the appropriate 32- or 64‑bit OS localisations on Windows 7 and Windows 8 workstations but aborts on servers and elderly relations like Vista, XP and 2000.
The script sets the system language and default new user language to Irish by referencing an XML file (provided), which I'll discuss in a while.
It finds out what version of Internet Explorer is installed.
The script is less obliging when it comes to localising Office and doesn't probe at all to see what versions you have installed. Sorry. There are only twenty-four hours in the day and I can only give so many of them on this little project so I had to be realistic.
Between Office 2007, 2010 and 2013, in 32- and 64‑bit flavours, there are ten localisation files (that almost-but-don't-quite keep to a consistent file naming convention). Then, you'd ideally want the script to be able to cope with any kind Office installation it might find, including different components of different versions of Office installed on the same Windows instance and any Microsoft Office-free workstations where LibreOffice was installed instead. That's a good share of
ElseIf logic. Writing the code mightn't be too bad but testing it would take more time than I have.
So the first compromise is that the localisation script is hard-wired to deploy 32-bit installers only, because 64‑bit Office is still a product that you need a good reason to install (ref) and it often won't have been; although the wire's very conspicuous and easy to cut if it has. The second compromise is a string variable that has to be edited manually before the script's run to tell it if the machines are running Office 2007, 2010 or 2013... so yes, that means it will only install localisations for one of them. I know, it isn't a bit elegent but it is reliable and it does the job.
If you've used WSUS to deploy Language Packs or Language Interface Packs you might wonder why anyone would mess around doing it with scripts and XML files. Have a look at this screenshot of the Windows product updates that are available under WSUS options:
There's a Language Packs for Windows Server 2012 option out of view, further down the product list but as you can see, there's no mention of Windows 7 Language Interface Packs. Now have a look at the range of updates available for Office:
No mention of localisation packages at all here. Perhaps they just come included with Office product updates (I haven't tested for this but I doubt it). Whether they do or not, when you put these Windows and Office settings together this is the result as seen in the All Updates list in the WSUS console:
Scottish Gaelic and Welsh LIPs for Windows 8 are out of view in the screenshot but they do appear further down the list. Clearly though, the only Celtic LIPs on the menu are for Windows 8.
So even if you were to get WSUS to deploy Windows 8 LIPs you'd still need another way to see after Windows 7, Internet Explorer and, probably, Office. And you'd still need a script to set the global UI language. And you'd have to get
wuauclt.exe /detectnow to nag the workstations into updating themselves in a sensible space of time. All of which means that you wouldn't have a single, clean, self-contained, wind-it-up-and-off-it-goes localisation method any more.
Starting with version 3.0, as I understand it, it is possible to get WSUS to deploy custom updates (ref). I haven't looked into this at all yet but I'll come back to it at some point, although I doubt it will eliminate the need for a certain amount of scripting.