when to, or to not, use toLocale methods?

Question

TLDR below

I was reading through the Standard Built-In Objects portion of JavaScript on MDN and noticed that there are these methods that utilize 'Locale' and are used specifically, from what I can gather, to format return text from the method in a locally defined format if it exists. Apparently it causes an issue with Turkey(I don't know if there are others)

As far as I could tell, from what I've looked into, these were all implemented in ES 5.1 circa 2011. In fact, in one of the SO links in the references below it's actively pointed out that a reason why Angular 1.x might be using toString instead of toLocaleString is because of backwards compatibility with browsers that didn't yet completely adopt ES5.1 - simple aside: I don't know if that's exactly the case but it seems reasonable.

so I looked up the ES6 spec to check out the method:

On Object:

15.2.4.3 Object.prototype.toLocaleString ( ) This function returns the result of calling toString(). NOTE This function is provided to give all Objects a generic toLocaleString interface, even though not all may use it. Currently, Array, Number, and Date provide their own locale-sensitive toLocaleString methods. NOTE The first parameter to this function is likely to be used in a future version of this standard; it is recommended that implementations do not use this parameter position for anything else.

On Array:

15.4.4.3 Array.prototype.toLocaleString ( ) The elements of the array are converted to strings using their toLocaleString methods, and these strings are then concatenated, separated by occurrences of a separator string that has been derived in an implementationdefined locale-specific way. The result of calling this function is intended to be analogous to the result of toString, except that the result of this function is intended to be locale-specific.

On String:

15.5.4.17 String.prototype.toLocaleLowerCase ( ) This function works exactly the same as toLowerCase except that its result is intended to yield the correct result for the host environment’s current locale, rather than a locale-independent result. There will only be a difference in the few cases (such as Turkish) where the rules for that language conflict with the regular Unicode case mappings. NOTE The toLocaleLowerCase function is intentionally generic; it does not require that its this value be a String object. Therefore, it can be transferred to other kinds of objects for use as a method. NOTE The first parameter to this function is likely to be used in a future version of this standard; it is recommended that implementations do not use this parameter position for anything else.

The original ToLowerCase for Clarity:

15.5.4.16 String.prototype.toLowerCase ( ) If this object is not already a string, it is converted to a string. The characters in that string are converted one by one to lower case. The result is a string value, not a String object. The characters are converted one by one. The result of each conversion is the original character, unless that character has a Unicode lowercase equivalent, in which case the lowercase equivalent is used instead. NOTE The result should be derived according to the case mappings in the Unicode character database (this explicitly includes not only the UnicodeData.txt file, but also the SpecialCasings.txt file that accompanies it in Unicode 2.1.8 and later). NOTE The toLowerCase function is intentionally generic; it does not require that its this value be a String object. Therefore, it can be transferred to other kinds of objects for use as a method

(toLocaleUpperCase/toUpperCase reads exactly the same)

Given all that, and with the release of ES6 and it being largely adopted I am confused. I feel that toLowerCase and toUpperCase are used pretty commonly for validation purposes(though less so with ES6) and changing them to utilize Locale seems wrong because you would be checking against unknown formatting. So Okay, not really useful for validation. So what about outputting to the DOM with toLocaleString? It seems plausible, but again, you're dealing with unknowns. Say your locale isn't formatted and you wanted the integer 1000 to be displayed as '1,000'. (I've read that this happens with en-GB) It will leave it out of your hands and you may never even know that it's not displaying as you wanted it to.

TLDR: Is there a practical use case for methods like toLocaleString toLocaleLowerCase toLocaleUpperCase, etc.? Should they be largely ignored?

Note: I realize this is on the line of opinionated, but I don't think it is. I'm looking for rational cases in which these may be applicable if they exist. e.g. like asking 'what you would use .call for' as opposed to 'do you think .call is better than .apply'

References

MDN String Prototype: toLocaleLowerCase

SO: Difference Between toLocaleLowerCase and toLowerCase?

SO: In which exactly js engines are toLowerCase toUpperCase locale sensitive?

SO: JavaScript difference between toString and toLocaleString methods of date?

Answer 1

It seems plausible, but again, you're dealing with unknowns.

Yes. You need to get to know them.

It will leave it out of your hands and you may never even know that it's not displaying as you wanted it to.

Indeed. If you want/need to have full control over your output, you need to implement the formatting yourself. If you only say, hey, it's a number, please format it to whatever you think is best for a British locale, then you can use it.

Is there a practical use case for methods like toLocaleString etc.?

Yes! You will want to use them in an environment that supports the ECMA-402 Standard.

From the API Overview:

"The ECMAScript 2016 Internationalization API Specification provides several key pieces of language-sensitive functionality that are required in most applications: String comparison (collation), number formatting, date and time formatting, and case conversion. While the ECMAScript 2016 Language Specification provides functions for this basic functionality (on Array.prototype: toLocaleString; on String.prototype: localeCompare, toLocaleLowerCase, toLocaleUpperCase; on Number.prototype: toLocaleString; on Date.prototype: toLocaleString, toLocaleDateString, and toLocaleTimeString), it leaves the actual behaviour of these functions largely up to implementations to define. The ECMAScript 2016 Internationalization API Specification provides additional functionality, control over the language and over details of the behaviour to be used, and a more complete specification of required functionality."

Should they be largely ignored?

In an unknown environment, probably. But not when you know what they do (because you control the environment, or you expect it to conform to ECMA-402), because in those cases they can be very useful and take a great deal of work off you.