DEV Community: Amandeep Singh Malhotra

Solving Locale-Related String Formatting Woes in Java

Amandeep Singh Malhotra — Sun, 01 Oct 2023 14:33:49 +0000

Imagine you are working on a piece of code that is running absolutely fine on your machine and you think you've got everything covered. But then, you run into the dreaded locale problem. Your beautifully formatted strings look completely different when someone on the other side of the globe runs your code. All your well crafted tests seem to fail! 😩

Well, fear not, my fellow developers! In this blog post, we're going to dive deep into the world of locale-related string formatting and how you can solve this issue to ensure consistency in your code, no matter where it's run.

The Locale Conundrum

Locale, in programming terms, refers to the cultural and regional settings that influence how data like dates, numbers, and currency values are formatted and displayed. Different countries and regions have different conventions for things like date formats, decimal separators, and currency symbols.

Consider this simple example in Java using String.format:

String formattedAmount = String.format("Amount: %.2f", 1234.567);

If you run this code in India, you might expect the result to be "Amount: 1234.57" with a period as the decimal separator. However, if your colleague in Germany runs the same code, they might see "Amount: 1234,57" with a comma as the decimal separator.

Why the difference? It's all about the locale. In India, the default locale typically uses a period as the decimal separator, while in Germany, it's a comma.

The Solution: Explicit Locale Specification

To ensure consistent formatting regardless of the user's location, you can explicitly specify the locale you want to use with String.format. Here's how you can do it:

import java.util.Locale;

// Specify the desired locale
Locale usLocale = new Locale("en", "US");

// Now use it with String.format
String formattedAmount = String.format(usLocale, "Amount: %.2f", 1234.567);

By specifying the usLocale (United States) explicitly, you ensure that the formatting will always follow the conventions of that locale, which uses a period as the decimal separator.

More Locale-Sensitive Formatting

String formatting is just the tip of the iceberg. The locale can affect many aspects of your application:

Dates

Locale frenchLocale = new Locale("fr", "FR");
String formattedDate = String.format(frenchLocale, "Date: %tD", new Date());

In France, this would display the date in the "dd/MM/yy" format, while in the United States, it would be "MM/dd/yy."

Currency

Locale japaneseLocale = new Locale("ja", "JP");
double price = 1234.56;
String formattedPrice = NumberFormat.getCurrencyInstance(japaneseLocale).format(price);

In Japan, this would format the price with the yen symbol (¥), while in the United States, it would be formatted as $1,234.56.

Conclusion

Locale-related string formatting issues can be a headache, but they are easily solvable by explicitly specifying the desired locale in your code. This ensures consistent formatting and a better user experience for your international audience.

Remember, when it comes to internationalization, a little locale awareness goes a long way! 🌍🌎🌏

Happy coding! 🚀👨‍💻

New to JS? Understand ‘this’

Amandeep Singh Malhotra — Mon, 04 Jul 2022 03:44:44 +0000

The ‘this’ keyword is a simple concept but can be sometimes tricky to understand by developers who are new to the Javascript environment. Mostly because in JS, the behaviour of this is slightly different than other programming languages (such as Java, for example).

So what’s this?

To put simply, this is a reference to an object. Which object you may ask? Well that depends on the context of the code this is used in. The context depends on the scope where the code was invoked.

Outside functions

If you use this outside of functions, i.e., in the Global Context, this will point to the global object, i.e., the window object. Recall that the window object allows the JS engine to interact with browser’s capabilities and functions. Let’s understand this through examples:

// displays the alert message in the browser
// works the same as window.alert() or just alert()
this.alert("This should alert out message in the browser"); 

// waits for 2 secs, then prints the message on the console
// works the same as window.setTimeout() or just setTimeout()
this.setTimeout(() => {
    // works the same as window.console.log() or just console.log(). You get the pattern now :)
  this.console.log("Hello from the browser");
}, 2000);

var helloObj = "Hello JS"; // declare variable in the global context
console.log(this.helloObj); // prints 'Hello JS' in the console

Within functions

Behaviour of this within functions is same as outside functions, i.e, this will still point to the global object. This is because the function is being called without the context of an object:

var greet = {
  message: "Hello!",
};

function fun() {
  console.log(this.greet.message); 
}

fun(); // 'Hello'

Within methods

Understanding the context of this becomes slightly trickier when used inside methods. Remember - the value of this depends on how the method was invoked and NOT on where the method was defined. For example,

var obj = {
  message: "Hello!",
  printThis: function () {
    console.log(this);  // 'this' points to object 'obj'
  },
};

obj.printThis();

But if we assign the method printThis of obj to another variable, we are executing the method in the global context. Hence this would be assigned to window.

var printThisGlobal = obj.printThis;
printThisGlobal(); // 'this' points to object 'window'

Note how the value of this is dependent on how these functions are invoked.

Important - Inner functions within methods will have global scope since the function would be called without the object’s context:

var data = "Global scope!";

var obj = {
  data: "obj scope!",
  showData() {
    setTimeout(function () {
      console.log(this.data); // prints 'Global Scope!'
    }, 2000);
  },
};

obj.showData();

But what if we want the inner functions to retain the object’s context? Well there are two popular ways to achieve this:

Method 1 - Store the context in another variable:

var data = "Global scope!";

var obj = {
  data: "obj scope!",
  showData() {
        var that = this; // storing the context in the that variable
    setTimeout(function () {
      console.log(that.data); // prints 'obj scope!'
    }, 2000);
  },
};

obj.showData();

Method 2 (My favourite) - Arrow functions:

Arrow functions take the context from the enclosing function, hence are cleaner if we want the function to retain the context of this:

var data = "Global scope!";

var obj = {
  data: "obj scope!",
  showData() {
    setTimeout(() => {
      console.log(this.data); // prints 'obj scope!'
    });
  },
};

obj.showData();

Within constructor functions

When using this within constructor functions (functions created using the new keyword), this points to the newly created object:

function Rectangle(height, width) {
  this.height = height; // this points to the 'Rectangle' object created using the new keyword
  this.width = width;
}

let rectangle1 = new Rectangle(5, 10);
console.log(rectangle1);

Remember to use the new keyword when using constructor functions to avoid setting variables within the function in the global context and subsequently end up polluting it.

Within classes

When used within ES6 classes, this keyword points to the current object created using the new word (this behaviour is similar to constructor functions). Only catch is that since strict mode is enabled by default when using classes, this would point to undefined for functions defined under non-static methods.

class Rectangle {
  constructor(height, width) {
    this.height = height;
    this.width = width;
  }

  getArea() {
    return this.height * this.width;
  }

  showHeight() {
    setTimeout(function () {
      console.log(this.height); // undefined
    });
  }
}

const rectangle = new Rectangle(5, 10);
console.log(rectangle.getArea()); // 50
rectangle.showHeight();

Conclusion

I hope this gives you a fair understanding of how this works in Javascript. Since this is important to understand other concepts in JS, it is extremely imperative that you understand it well.

The strict mode significantly impacts how this behaves, so be sure to check it out.

There are methods which allow you to explicitly set the value of this within objects. These are namely call, apply & bind. You can read more about these methods by clicking on the inline links. I will try to cover more on these methods in a separate article.

If there is something you feel I have missed in this article, do let me know in the comments section below.

References

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode

What the hell is ?

Amandeep Singh Malhotra — Wed, 29 Jun 2022 11:41:37 +0000

<!DOCTYPE html> <!-- What the hell is this?? -->>
<html lang="en">
<head>
    <title>Document</title>
</head>
<body>
</body>
</html

When creating a new HTML file, you might have wondered, “Why do I need to add this statement to the first line of my HTML file? Doesn’t the .html file extension suffice in telling the browser that this is an HTML file?”. While this is true, there’s still more to it. Before we understand the above statement, let’s try to understand what a DTD is.

Document Type Definition (DTD)

A Document Type Definition (or DTD in short) describes the document structure of an XML document along with a list of the legal elements the document can have.

Prior to HTML5 (for e.g. in HTML 4.01), all HTML documents would have to contain a “Doctype” declaration on its first line along with a reference to its type definition. This would look something like:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd">

This declaration served two purposes:

Provide the list of valid elements the document can contain.
Define the flavour of the DTD which could be strict, transitional or frameset. More on this here.

So why don’t you see these long DTD references in the latest HTML files you've encountered?

Enter HTML5!

See, earlier versions of HTML (prior to HTML5) were SGML (Standard Generalized Markup Language) based, and therefore required a reference to DTDs. HTML5 onwards, this reference was no longer needed since this version of HTML is not SGML based.

So now, this “Doctype” declaration serves another purpose. It allows browser to run the HTML file in a “Standard mode”. Now it’s logical to ask, “What on earth is this standard mode now??” To understand this, let’s go back in time.

Back in time

Back when tech enthusiasts realised the power of what would be known as the internet, two popular browsers came into existence - the Netscape Navigator & following its success, (drumrolls) Microsoft’s Internet explorer. This was even before the W3C standards came into picture which would eventually standardise how code would run across different browsers. Hence, you can imagine that, given the popularity of these browsers, websites were written in two versions - one for the Navigator, and the other one for IE, which might sound a little redundant now, but was the norm back then. However, after the W3C standards were created and browsers started adhering to them, developers encountered a new problem.

The problem now was that the legacy code started to break. Hence, a possible solution to this was that the sites were now made in two versions - a Standard version (the one which we mentioned earlier) which was W3C standards compliant and hence would run across different browsers and a Quirks version which supported the legacy code.

Now how do browsers identify which mode it needs to use? Well, just add a valid DOCTYPE declaration in the first line of the HTML file, to instruct the browser to run the code in Standard mode. Anything other than that will trigger the Quirks mode in IE9 or older. This is exactly what <!DOCTYPE html> does HTML5 onwards. If you fail to add this line to your HTML file, the browser would interpret this as an instruction to run your code in Quirks mode, and you could end up getting inconsistent results across different browsers.

Conclusion

With this little background in mind, I hope you now understand the importance of the <!DOCTYPE html> statement. If you’d like to read a little more on this, please go through the links I have provided as a reference below.

References

https://www.freecodecamp.org/news/what-is-the-doctype-declaration-in-html/
https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode
https://hsivonen.fi/doctype/