Set the default language trying to get it from the browser, or from the system locale (Node.js).

[DiegoZoracKy]

The module could try to get the language from navigator.language, or from the system local when running on Node.js, to set it as the default language. Instead of having 'en' hardcoded.

[EvanHahn]

I'm pretty hesitant to do this for a few reasons.

1. This would be a breaking change and certainly a big feature—something larger than I am willing to take on as a maintainer (see #120).
2. We'll always need to have a fallback anyway.
3. We'll need to have pretty significantly different code paths for Node and the browser. And what about other, more obscure JS environments like Rhino?
4. Will there be problems reliably detecting Node in environments like Browserify?
5. The code for determining locale in Node is pretty significant. We could include that as a dependency in Node only, but that gets hairy in part because of the previous point and in part because

That being said, I think this is a great candidate for something that should be documented as an example.

What do you think?

[DiegoZoracKy]

@EvanHahn, ok, but do you think it would be really useful to have a snippet for that as an example? My initial idea was to reduce the code needed to accomplish that, as I believe this is a common case and people are probably already doing it by hand.

[EvanHahn]

I'm not sure how many other people have this issue. If lots of other people do this, I think the snippet is helpful. We could put it lower down in the readme or even in the GitHub wiki.

Or what about a companion library that grabs the language? Something like this:

const humanize = humanizeDuration.humanizer({
  language: getLanguage(navigator.language)
})

Neither of these require code changes to the library.

[DiegoZoracKy]

"I'm not sure how many other people have this issue. If lots of other people do this..."

I believe this is probably a very common use of this library. I can think quickly about some scenarios:

A app with i18n is being created (front-end) The goal would be to show it using the same language as the user (supposing that the whole app in case has support for the user language). Guessing from the user's environment will be needed.

Creating a program for use internally, by one and his team (back-end) The goal would be to have it using the same language as the people from the team, and they are not from some country with English as the main english. A language setup will be needed, and if it could get from their own environment, everything would be already set.

A app without i18n is being created (front-end) The goal would be to have it using one unique language. Even if we think that, for example, an app in portuguese would be probably be used only on portuguese countries, so guessing from the user could also work well In this case. I believe that would be better to harcoded it. Just to maintain an integrity if someone from another language would end up using the app.

But I'm bringing these just to explain about why i have thought about that. I got your point. Maybe examples could solve better at this time.

[EvanHahn]

I think you're totally right.

Do you want to make a pull request to add an example to the readme? You could also comment below and I could add it myself.

[DiegoZoracKy]

I'll find some time to do that.

[EvanHahn]

@DiegoZoracKy Have you made any progress with this? No worries if not, just checking in.

[DiegoZoracKy]

Hi @EvanHahn. Sorry, I'm currently having just a bit of free time per day and I'm using it to finish a new module that I've been creating. The idea is to release it soon. So after that maybe I can get back to this issue, ok?

[EvanHahn]

I'm going to close this issue because this module is in maintenance mode (see #120). Feel free to continue discussion here and we can see about adding something to the readme or endorsing a fork.