-
Notifications
You must be signed in to change notification settings - Fork 991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
detect a user's locale using os-locale #231
Conversation
options.choices && options.choices[key] ? '[' + __('choices:') + ' ' + | ||
self.stringifiedValues(options.choices[key]) + ']' : null, | ||
defaultString(options.default[key], options.defaultDescription[key]) | ||
].filter(Boolean).join(' ') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change is out-of-scope, PR denied.
j/k
Sorry, not sure if comments for the sake of humor are allowed yet. 😎
On the outset, this LGTM, but I want to devote a little time to branch testing before I give the thumbs-up. Should be able to complete that later today. |
@@ -533,6 +535,10 @@ function Argv (processArgs, cwd) { | |||
}) | |||
} | |||
|
|||
function guessLocale () { | |||
return osLocale.sync().split('_')[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking it would be better to have y18n fall back to "language only" code (e.g. es
) if no locale/json file is found for "language_territory" code (e.g. es_MX
). Then we wouldn't have to worry about doing the split on '_'
here, which could be prohibitive of adding territory-specific translations to yargs in the future.
What do you think? Perhaps I can put together a PR for y18n to address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nexdrew I agree, good call. I'll add you to the y18n project too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bcoe FYI y18n@3.1.0
has been released and should remove the need to split result of osLocale.sync()
@@ -311,6 +311,30 @@ describe('yargs dsl tests', function () { | |||
}) | |||
|
|||
describe('locale', function () { | |||
it('returns locale if locale is called with no arguments', function () { | |||
yargs.locale().should.equal('en') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assertion changes with y18n@3.1.0
:
yargs.locale().should.equal('en_US')
Should probably loadLocale('en_US.UTF-8')
at beginning of this test, in case it's running on a travis-ci build agent with a different default locale?
My manual tests on Mac and Windows both look good. 👍 |
detect a user's locale using os-locale
This pull moves us to phase 2.0 of locales in yargs, we now automatically detect the operating system's locale using @sindresorhus' os-locale module.
outputs:
Opções: -h, --help Mostra ajuda [boolean] --foo what up fool [padrão: 99] --config i be config yo [padrão: "./cool.json"] -x [padrão: 10]
now we just need to work on getting some more translations.
reviewers: @nexdrew, @nylen