Update package.nls.json: typos and light editing.

[hunterhogan]

Fixed some typos. Quick, light edits to improve some other things.

[hunterhogan]

@microsoft-github-policy-service agree

[alexr00]

Thanks for the PR, but these changes don't seem to be needed.

[hunterhogan]

Thanks for the PR, but these changes don't seem to be needed.

Hubris.

[jorenham]

Thanks for the PR, but these changes don't seem to be needed.

Out of curiosity: Why not?

[hunterhogan]

Thanks for the PR, but these changes don't seem to be needed.

Out of curiosity: Why not?

Also, to again be additionally fair as well, "Can also be set to additionally merge updates from the base branch.", is moreover a style choice, furthermore isn't it, too?

Complete sentences? Ain't nobody got time for that.

Can also be set to additionally merge updates from the base branch.

Sentence fragments are the future: complete sentences "don't seem to be needed."

[jorenham]

Complete sentences? Ain't nobody got time for that.

I understand the unwillingness to change things purely out of personal preference. Maybe you missed it, but this PR also addresses several grammatical issues. Leaving those in can actually cost users time, because sentences with bad grammar are more difficult to interpret, and that takes time. Also, the existence of this PR shows that there are users are actually willing to donate their time in order to fix these mistakes.
As for the trailing periods, I doubt that I would notice that myself, so I don't care much about them. But in the same way, I don't see why that means that there shouldn't be periods at the ends of sentences, either.

Sentence fragments are the future: complete sentences "don't seem to be needed."

note the trailing period.

But I think the main issue here is the lack of empathy in your "sentence fragment". Because it could easily be (mis?)interpreted as a sign of disrespect to the invested time and effort.

Don't get me wrong; this is a mistake I've made myself, which I've later come to regret and have apologised for. And to be honest, I'm still kinda bad at online communication, so this lecture is also directed at myself.

So just to be clear; it's not that I'm accusing you, @alexr00, of having bad intentions or anything. It's just that don't want to see users of great open open-source tools (like this one) from becoming cynical and unwilling to contribute to such projects in the future. And since I maintain several open-source projects, I guess it would be fair to label that as self-interest.

[hunterhogan]

Maybe you missed it, but this PR also addresses several grammatical issues.

I made the pull request.

It's just that don't want to see users of great open open-source tools (like this one) from becoming cynical and unwilling to contribute

This experience and many other negative experiences have already curtailed my contributions.

The importance of grammar, including punctuation, in this project might be more important than you realize. See #7362 (comment)

[jorenham]

Oh sorry I seem to have tagged the wrong person, sorry about the confusion

[alexr00]

The changes are just to strings, they are extensive and take time to review, and I, and the users who want more features or bugfixes, would prefer to spend that time adding features or fixing bugs.

Also, this looked like the kind of PR that someone makes with an llm just to boost the PR stats on their account. We get a lot of issues and PRs across the repos that the VS Code team manages, and so we have a limited amount of time to spend on each one. When something looks iffy the most time-effective path to take is close it.

Given the amount of engagement from the OP though, this seems less likely now. We usually have a month later in the year where we have time to invest in PRs like this. I can reopen the PR and look at it then.

[hunterhogan]

this looked like the kind of PR that someone makes with an llm just to boost the PR stats on their account.

Thank you for telling me about this. I hadn't considered this perspective, and I am glad I know about it now.

I read a lot of documentation because I'm a mediocre programmer. I'm a well-trained editor, however, so improving the documentation is relatively low effort for me.

Your advice

How can I help maintainers, such as you, separate the PR wheat from the LLM chaff--but without adding so much more effort that the pull request isn't worth my time?

[alexr00]

Providing a PR description which gives the motivation for the change would help!