My app is translated in several languages with i18next. Until now, I used only one English translation. But I'd like to have both en-GB and en-US. Truth is, text translations will be the same and the only reason I want both languages is for date formats.
More precisely, I want to pass the good date format to a MUI DatePicker component. Right now, English has MM-DD-YYYY format, unlike most other languages. Obviously, I'd like en-GB to have DD-MM-YYYY format.
Is this rather common use case built in i18next or should I use some kind of hack to avoid having two almost identical translation files to maintain ?
Related
My computer is defined to use 24h format:
However, when I use var date = new Date("10/25/2020 19:32")
and then date.toLocaleTimeString()
I get a 12h format:
When no options are provided, the output of toLocaleString is entirely implementation dependent so may or may not use host settings, however they are almost certain to treat it as equivalent to a language of "default" with no options, i.e.
new Date().toLocaleString('default') === new Date().toLocaleString()
which returns true in every browser I tested. The important part is:
[toLocaleString is] intended to represent the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment's current locale.
Note that it should use the conventions of the locale (i.e. place or region), not the host system.
When a language and/or options are provided, the output is governed by ECMA-402 and is primarily based on the language code provided as the first argument (misnamed "locale"). Options also affect the output, however the host settings are not used other than to obtain the language code to use in the case of "default" for the first argument.
The underlying principle of the toLocale methods is that appropriate formatting can be determined from a language and other fairly vague options. Implementation developers then work out what format to use for each language and option combination. Clearly the host system settings can't be used when language or options are provided as that defeats the entire purpose of the function.
Your assumption that the browser will use the settings in the operating system is probably wrong.
You leave it to the browser to choose a locale for you.
My guess is that it is based on window.navigator.languages. This could be "en-US" in your case, hence the 12h format.
I am currently working on a web application and I try to make the website multilingual.
From The user I got the following things:
language - from $_SERVER['HTTP_ACCEPT_LANGUAGE']
country - from the useres IP address (with an API)
Now, the website takes the language and shows the page in the correct language - for example english or german. Now I want to format numbers and dates and I dont know what should I use to format a date for example:
Germany: dd.MM.yyyy
United States: MM/dd/yyyy
But what should I use to format the date? The language or the country?
What if a user is in the US but speaks german? Should I use the US or the german format?
Would be nice to hear your opinion about that and how you handle localization.
The questions you are asking are solved using Locales. A locale is specific to a language, and then possibly more specific with geographical information and script variants.
CLDR is a repository of information relating to locales. You can find the names of specific cities in any languages, for example, or see how they format dates in a specific area.
You can leverage this data in conjunction with the Globalize.js library and its date formatting module.
See this answer for a general overview of how to use Globalize.js.
As momentjs has the ability take into account the date format for differernt locales, does it have the ability to localize time (hour:minute) format?
According to oracle docs time format there're some time format difference across region
https://docs.oracle.com/cd/E19455-01/806-0169/overview-6/index.html
moment().locale(somelocale).format('L') this will output the formatted date
However
moment().locale(somelocale).format('LT') doesn't seem like to have the same ability?
class TimeFormatter extends React.Component {
render() {
const browserLocale = window.navigator.userLanguage || window.navigator.language;
return (
<div>
{moment(this.props.value, 'HH:mm').locale(browserLocale).format('LT')}
</div>);
}
}
Above is my code for formatting the time cell on react data grid, but while I change the chrome settings the format stays the same.
So if I want to achieve time format localization can I use momentjs or I have to just come up a if else condition for setup specific user region time format
Many Thanks
The LT format does take locale into account.
Here are some examples:
moment().locale('en-CA').format('LT') //=> "1:21 PM"
moment().locale('fr-CA').format('LT') //=> "13:21"
moment().locale('fi-FI').format('LT') //=> "13.21"
moment().locale('de-DE').format('LT') //=> "13:21"
moment().locale('no-NO').format('LT') //=> "1:21 PM"
moment().locale('th-TH').format('LT') //=> "13:21"
moment().locale('en-GB').format('LT') //=> "13:21"
Note that the Oracle page you linked to is part of the Solaris 8 documentation - an operating system which came out in February 2000 and reached end of life in March 2012. It is sorely mistaken with regard to the time formats used in those countries and languages. You should not use it as a reference.
Also note that that it made a grave error in assuming that "Canadian" was enough to identify a locale completely. As shown above, French speaking Canadians use a 24-hour clock, but many English speaking Canadians sometimes use a 12-hour clock (see Time notation in Canada) and thus en-CA gives the 12-hour format while fr-CA gives the 24-hour format.
Thus, country alone is not enough. A locale must consist of at least language, but usually both language and country are necessary. These are now called "IETF language tags" and are standardized by BCP 47.
As far as why Moment's German localization doesn't include the string Uhr in the result, that was something that was first added with #1601, but then removed with #2006 - both back in 2014. See those issues for reasoning.
Also note that Moment's localization strings come from community submitted feedback and moment contributors. In many cases they align to the standards collated by Unicode CLDR, but in some cases they differ. If you are looking for a modern date library with standardized localization support, consider Luxon which leverages the internationalization APIs built into modern browsers.
I reside in Canada, where we format our dates dd/mm/yyyy. I'm seeing something unusual when I'm calling toLocaleDateString()
HTML:
<input type="date" value="2016-01-13">
<p id="container">
</p>
JS:
var d = new Date("2016-01-13");
document.getElementById('container').innerText = d.toLocaleDateString();
The value of the date input is what I would expect - 2016-01-13.
The value of the paragraph is the American format - 12-01-2016 (the change in day is due to localizing from GMT to EST)
Chrome language is set to Canadian, as is my system setting (Windows 7). The date input seems to be respecting that, but I thought toLocaleDateString() would pick up Canada as my locale and format the date appropriately.
MSDN describes this function like this:
dateObj.toLocaleDateString( [locales][, options])
locales (Optional). An array of locale strings that contain one or more language or locale tags. If you include more than one locale string, list them in descending order of priority so that the first entry is the preferred locale. If you omit this parameter, the default locale of the JavaScript runtime is used.
Is the JavaScript runtime default locale something the user can change? I'm guessing not given my lack of success.
The different formatting between the date input and toLocaleDateString is quite baffling to me, any thoughts on how I can align the two?
http://jsfiddle.net/DfkU5/283/
Is the JavaScript runtime default locale something the user can change?
That depends entirely on the browser developers, they can do whatever they like. However, they tend to use system settings, but not always. Chrome ignores my settings for toLocalString, showing dates in m/d/y format when my preference is for d/m/y.
Safari, Chrome and Firefox all show a different string for toLocaleDate, which makes it just about useless.
The different formatting between the date input and toLocaleDateString is quite baffling to me, any thoughts on how I can align the two?
By far the best solution is to present dates in an unambiguous format, the easiest being to use the month name. All the following are unambiguous and easy to read:
19-Mar-2016
March 19, 2016
19 March, 2016
To do that you can write your own formatter (maybe 10 lines of code), or perhaps use a library.
In regard to input type date, not all browsers support it and there are lots of issues, so if you're going to use it you must check for support (fairly trivial) and if lacking, provide a fallback that does something sensible. And once you have a good fallback, you might as well implement it everywhere and forget input type date.
Then all the issues associated with it are gone. ;-)
Pass your locale as an arugment to toLocaleDateString()
e.g:
date.toLocaleDateString('en-CA')
or if you want to specify some fallback language, do this
date.toLocaleDateString(['en-CA','en-US'])
Check here
I’m trying to format some numbers with jQuery. I would like to get the user’s regional settings for currency and number, in order to implement the correct format (obtain the decimal separator).
Is it possible to retrieve these parameters with jQuery or JavaScript?
Use Number.toLocaleString() with style:'currency':
(73.57).toLocaleString('de-DE',{style:'currency',currency:'EUR'}); // German: 73,57 €
(73.57).toLocaleString('en-US',{style:'currency',currency:'EUR'}); // American: €73.57
Note that:
This does not get regional settings, but provides output in regional settings.
If you want your locale to be determined dynamically, use navigator.language.
There are many other means aside from this native approach; for starters, take a look at accounting.js or Stack Overflow answers like this one.
As Daniel Jackson commented:
Using Intl.NumberFormat.format(), you can achieve identical results, with the NumberFormat and the general Intl objects offering versatile options and methods with a main focus on language sensitivity.
new Intl.NumberFormat('de-DE',{style:'currency',currency:'EUR'}).format(73.57); // DE: 73,57 €
new Intl.NumberFormat('en-US',{style:'currency',currency:'EUR'}).format(73.57); // US: €73.57
There is a jQuery plugin for it - https://github.com/dansingerman/jQuery-Browser-Language
See this SO answer for more info JavaScript for detecting browser language preference