X,XXX
PRs welcome.
When I meant localized numbers I meant clients should use the respective number formatter API to format numbers.
For example in Java we use the NumberFormatter which defaults to the system locale, then you give it a normal delocalized number and it'll output the localized form for the users configured locale on the system.
The locale is a system setting, that's not our responsibility.
We would only be responsible if we support it for making denoting numbers in the docs, so a client can localize them.
For example:
- A number between 1 and 10000. (should be localized)
- Set the port to 3306. (shouldn't be localized)
If we supported localization, the client would have to know which should be localized, and which shouldn't.
This could either use a dedicated syntax, or numbers with underlying meaning could always be wrapped with backticks maybe, ie 3306.
Then a client would just pull out 10000.
On my machine it'd output 10,000, but on another machine it might do 10 000, etc etc.
We don't have to care about all the different formats.
Number formatter in JavaScript for example, which can be used on a web based version:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat
And in Canada, the French speaking province still use Canada's locale.
YYYY-MM-DD
Yush, I don't think dates are a big concern though in our case since it's pretty standard. I'm also in favor YYYY-MM-DD in general since it tailors better to international audiences. (avoids the MM/DD mix up)
For numbers, regardless of whether we want to localize or not, I think ensuring all numbers are delocalized is an important step.
Either delocalized, so everyone can interpret numbers the same way we use numbers in code/data types, or so it can be localized later. (either way it'd need to have no localization in the files)
It was mostly just a question of, should numbers that could be localized be marked in some way so that a client could interpolate them or not.
I can try summarize the discussion on GitHub and here in an issue later tonight
:) from CONTRIBUTING.md
...
3. Try to incorporate the spelled-out version of single-letter options in the example's description.
The goal is to allow people to *understand* the syntax of the commands, not just *memorize* it.
4. Introduce options gradually, starting with the simplest command invocations,
and using more complex examples progressively.
5. Focus on details specific to the command, and avoid explaining general UNIX concepts that could apply to any command
(ex: relative/absolute paths, glob patterns/wildcards, special character escaping...).
These are all guidelines, not strict rules.
Use proper judgement, keeping simplicity and user-friendliness as the top priorities.
When in doubt, have a look at a few existing pages :).
## Markdown format
As a quick reference, the format of each page should match the following template:
# command-name
> Short, snappy description.
> Preferably one line; two are acceptable if necessary.
> More information: <https://url-to-upstream.tld>.
...
2 replies
Wrote an issue for the number locaization thing with 3 possible options:
tldr-pages/tldr#6147
Feel free to drop any further comments or if I missed anything.