PHP setlocale depends on underlying system (XAMPP on Windows)

I’m maintaining a few websites, so I have a local webserver running to do testing and debugging. Until recently, I was using IIS on my Windows laptop. However, I ditched IIS a while ago, replacing it with XAMPP. This is much closer to the environment that’s running the websites (e.g. I can use .htaccess directly, rather than converting it to a web.config file).

This all worked fine, except for setlocale in PHP. I wanted to use Dutch (Belgian), but I could not get
setlocale(LC_ALL, 'nl_BE');
to work on my local machine.

I searched the web, but did not find any useful information. So I looked at the PHP setlocale helpinfo again, and noticed the Tip in the NotesWindows users will find useful information about locale strings at Microsoft’s MSDN website.

After checking, it turned out that Microsoft decided to go for another “standard”, so ‘nl_BE’ was not recognized. To use Dutch on Windows, I needed
setlocale(LC_ALL, 'nld_nld');

Oh well…


2 Javascript discoveries

If you are an experienced Javascript developer, the following will not come as a surprise to you, but for those who might be struggling with some of the quirks of this otherwise pretty useful language, I’d like to share 2 discoveries. I spent quite some time trying to understand why certain code wouldn’t do what I intended and after several frustrating hours, I finally found that

  • Javascript is not a pure “pass-by-value” language, as I thought. When passing an object to a function, any changes to the internals of that object within the function, will alter the object outside the function.
  • A long-running JavaScript will freeze the browser, preventing it from being updated, so any visual changes will not be visible, until after the processing has finished.
    • Solution: Add a delay (even a 0ms delay) between making a visible change, and starting the script. Add this delay using setTimeout():


  • Some complex code on one of my websites didn’t behave properly, even though the code looked fine. Eventually I learned that an object that I passed to a function should not be altered within that function, as it directly changes the object itself, rather than a copy, which would be the case in a pure “pass-by-value” language. See for details.
  • I’m using the powerful datatables plugin on my websites. As some tables contain a lot of columns, I wanted to provide shortcuts to dynamically show or hide certain columns. You can do that with the column().visible() method, but as the table is large, it takes a few seconds to see the result. I therefore wanted to show the user that some processing was going on, with a small popup or by adding a “changing” class to a DOM element. However, these visual changes did not show, or better, they only showed AFTER the processing was done. I really didn’t understand why it was not working, until eventually gave a clue: “A long-running JavaScript will freeze the browser, preventing it from being updated.” Using setTimeout() with a delay of 0ms finally solved it.

Using JSConsole to debug an javascript issue on an iPad

Yesterday I ran into an issue with one of the websites I’m developing. All of a sudden, some pages would not show correctly on an iPad. However, as Safari on the iPad doesn’t provide “developer tools”, it was nearly impossible to determine what went wrong. The pages were working fine on other devices, including a normal laptop and an Android phone. Also Chrome’s emulation mode did not show any problems.

Digging into the Settings on the iPad, I found the “Web Inspector” option in the Advanced Settings tab for Safari. It states “To use the Web Inspector, connect to Safari on your computer using a cable and access your iPad from the Develop menu.” That’s fine if you have a Mac computer, but I only have Windows PC’s…

Luckily, after some Googling, this website from Leon Atherton came to the rescue. While it covers Remote Debugging on OS X, it also provides information about a cool web app called JSConsole. You simply need to add a script tag into your web page and that will capture any console.log input.


Pretty neat.

PS. The issue was linked to the use of arrow functions in one of my javascript pages. Those are not supported in Safari. And not in IE either, apparently. Which is a pity as they made a piece of code where I used the every() method a bit more compact. So I instead of

I now have to use:

Oh well…