I think most of the command line utilities accept the switch -h or --help. In my opinion we should only keep those that have anything apart from this (I do not have an example handy)

• [x] The PR title conforms to the recommended templates.
• [x] The page follows the content guidelines.

A common command I use a lot, felt it could be useful here

@SethFalco I don't think this template will change very often and I don't really like the idea of having another folder in the repository.

Thanks everyone, honestly I just saw a missing bit of info and did everything through the github ui, I'm surprised it tried to merge into master if your branch is called main. I'll fix up those issues too :)

with -s without the full command doesn't have enough sense, also I think should be a gitconfig setting to auto sign tags.

Alphabetic order:

`aws s3api get-bucket-policy --bucket {{bucket_name}} --query Policy --output {{json|table|text|yaml|yaml-stream}} > {{path/to/bucket_policy}}`

Ok, if smb:// doesn't work this is ok then.

I think this is the correct order:

- Owen Voke ([@owenvoke](https://github.com/owenvoke))
  [11 January 2018](https://github.com/tldr-pages/tldr/issues/1885) — [26 August 2018](https://github.com/tldr-pages/tldr/issues/2258)
- **Muhammad Falak R Wani ([@mfrw](https://github.com/mfrw))**:
  [6 September 2018](https://github.com/tldr-pages/tldr/issues/2306) — [21 June 2021](https://github.com/tldr-pages/tldr/issues/6142)

> More information: <https://manned.org/mklost+found>.

closes: #6142

Let's just go with Display help as @navarroaxel suggested, and we can discuss whether or not to include --help examples in a different issue (I think that's coming soon :)

Whoa, sorry, totally lost track of this.

Invite sent, awaiting reply

@mfrw, can you open a PR to update the MAINTAINERS.md please? :-)

Sure :)

There were some conflicting changes requested. I modified the file to address them. Let me know if you want any additional changes.

How about "StarDict command-line version, dictionary client. Dictionaries are provided separately from the client. "

Hi all! This thread has not had any recent activity. Are there any updates? Thanks!

I want to include"StarDict command-line version" somewhere, because that's what the acronym is.

In terms of result/usage, my favorite is Option 3. However, I concede to all points made above. I think it'd be nice to keep in mind the possibility. Perhaps it's something that could be considered when or if there are plans for other major changes that would impact clients.

I think Option 1 is a good candidate. That would also mean only one page would need update:

Benchmark a database with 10 clients, 2 worker threads, and 10,000 transactions per client: - pgbench.md

The only strong opinion I have is to reject Option 2, which both of us suggested separately at one point. After peeking into the language vs locale thing, it's not really a valid option for this. (Worth documenting the thought anyway.)

Great writeup here. Option 3 looks interesting, but as mentioned here it has a number of issues:

1. Additional custom syntax for pages
2. Additional complexity for clients
3. "Dumb" clients that don't support the new syntax results in displaying syntax that may be confusing for the user
4. CommonMark doesn't (as far as I know) have any official syntax for this for us to follow either

To be honest, given that the longest number in all of our pages right now is only 6 digits I think that option 1 (no localisation) is probably the best option for now.

I'm proposing that the style guide be updated to include how we approach localization of numbers, or if they should not be localized at all.

This discussion is only regarding numbers, not dates. This can be discussed further here if there is more to be said, but in general, it's believed using ISO/RFC standards like YYYY-MM-DD would be best, and avoids ambiguity between MM and DD.

You can see previous discussion on:

• https://github.com/tldr-pages/tldr/pull/6069#discussion_r654959704
• Matrix / Gitter

Option 1: No Localization

We should not have any localization applied at all. Instead, only the delocalized form should be used, like what we typically use in configuration files, command-line, or programming.

For example, the following would be invalid:

• 1,337.42
• 1.337,42
• 1'337.42
• 1 337.42

The correct form would be: 1337.42

This should be universally understood but all CLI users, but could make larger numbers harder to read. However, this may be a non-issue as the longest number in the repository is only 6 digits.

Specify the initial packet length (defaults to 65535 for IPv4 and 128000 for IPv6): - tracepath.md

Option 2: Localized to an Appropriate Locale

It has been suggested that we could hard-code a predefined locale with each language file.

For example:

• en could use en-US, which is 1,337.42.
• fr could use fr-FR, which is 1 337,42.

One problem with this approach is that languages and locales can't be mapped one-to-one. It suffers the same problem that happens when you try to map languages to country flags.

Languages can map to multiple countries, and this often also means multiple formatting rules. It's common for users to use one language, but another locale.

A real example, I use en-US for language, but en-GB for locale. (Only affects dates.) A hypothetical example, a Canadian that might use fr-CA for language, but en-CA for locale.

Even remaining in the same language.

• en-ZA (South African English) is 1 337.42.
• en-US (American English) is 1,337.42.

Option 3: Denote Localizable Numbers

I've suggested that we could denote localizable numbers, or numbers that can be localized for clients to handle localization using the system preference.

This would require the markdown files to have no localization at all, like in Option 1.

With this approach in mind, syntax would be required to denote which numbers can be localized to avoid falsely localizing numbers that shouldn't be.

For example, the following should not be localized:

• Port numbers (3306, 8080)
• Error/status/exit codes
• Cryptographic Key IDs (if one happens to end with 0-9 only)
• Date related numbers like the year (2019, 2021)

This means that all numbers that must be localized should be denoted somehow.

Clients can choose to strip out the notation, or interpolate the numbers with the locale of system. Clients may even choose to make it a toggle, or let users override the locale of the client to be separate from the system-preference.

The localization of numbers can be achieved easily, as it's built into most languages:

• JavaScript - Intl.NumberFormat or Number#toLocaleString
• Java - NumberFormat

This approach leads to more maintenance burden, as new pages will have to adhere to wrapping said syntax around numbers. Clients would also require an update to handle the new syntax.

Open for suggestions!

I'm thinking to remove this because it doesn't really feel right any more. It's also a bit personal, which seems inappropriate because the document is the voice of the whole community (or at least maintenance team).

Per the conversation on Gitter, I'm going to close this.

@waldyrious:

Hey @bl-ue, I will comment here for the time being, maybe later I might add more detailed feedback if the discussion is still ongoing. Honestly I don't have strong feelings either way. I like the emoji for the reasons others have pointed out, but it wouldn't bother me much if it were removed. Can you explain better why it bothers you that it's there? I'm not sure I understand the "voice of the community" concern. We do want to convey a friendly, informal, welcoming tone, and the emoji seems to help with that IMO. I'd actively support its removal only if some people interpret it as being sarcastic or passive-aggressive.

@bl-ue:

Of course, but too me emoji are better in message sent by obviously one person, whereas that document is written by a lot of people now. Back in March 2014 when it was written by Romain Prieto it was certainly him speaking for himself, but...

@sbrl:

That doesn't mean to say that the emoji can't echo the sentiment of the community as a whole

@waldyrious:

I think that may be just a cultural thing :) the wording of the document itself in no way conveys a personal voice, and I don't feel that using emojis gives that impression.

@waldyrious:

If others agreed that it did, I'd consider it worthwhile to rework that passage. I agree that the most we can encourage a collective voice in project docs, the better. But I don't think the emoji is working against that.

@bl-ue:

No, certainly not. It's difficult to put my finger exactly on what bothers me about it but I assure you it does so very little.

Other than discussing reasons, this should be simply voted for

Not quite. There's a "why I want to remove it" and a "why I don't want to remove it." 🙂