Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:58
    sbrl commented #6149
  • 12:46
    bl-ue labeled #6150
  • 12:40
    SethFalco opened #6150
  • 12:34
    SethFalco commented #6149
  • 12:28
    bl-ue commented #6139
  • 12:26
    bl-ue commented #6139
  • 12:25
    bl-ue unlocked #6139
  • 12:25
    bl-ue locked #6139
  • 12:12
    SethFalco synchronize #6078
  • 12:10
    bl-ue labeled #6149
  • 12:10
    bl-ue opened #6149
  • 11:58

    github-actions[bot] on main

    [GitHub Actions] uploaded asset… (compare)

  • 11:58

    owenvoke on master

    [GitHub Actions] uploaded asset… (compare)

  • 11:54

    github-actions[bot] on master

    MAINTAINERS: add @mfrw to org (… (compare)

  • 11:54

    mfrw on main

    MAINTAINERS: add @mfrw to org (… (compare)

  • 11:54
    mfrw closed #6148
  • 11:54
    mfrw closed #6142
  • 11:53
    mfrw commented #6148
  • 11:48
    bl-ue commented #6148
  • 11:46
    bl-ue synchronize #6148
bl-ue
@bl-ue
If you mean by "supporting localized numbers," dynamically intercepting \d+,\d+ and replacing , with . or ' as appropriate, I'm totally +1.
We'd need to standardize the format we format numbers with. Default would probably be comma X,XXX
bl-ue
@bl-ue
I'm trying to document this sort of thing here: https://github.com/bl-ue/tldr-notes#number-localization
PRs welcome.
Seth
@sethi:matrix.org
[m]

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.

Seth
@sethi:matrix.org
[m]

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

Starbeamrainbowlabs
@sbrl
Numbers should be localised to the language of the page
for example, on a French translation, numbers should be localised to French conventions
For english pages is slightly more complicated
but I would suggest that if necessary to follow en_US conventions
Seth
@sethi:matrix.org
[m]
That's not how locales work.
Language and locales are different things.
For example in France, even the English speakers use the France's locale.
And in Canada, the French speaking province still use Canada's locale.
Starbeamrainbowlabs
@sbrl
Oh, I see
that's awkward
it's infeasible to have 1 copy of each translation for each locale
Seth
@sethi:matrix.org
[m]
Yush, this is why we usually use Date/Number formatters to handle that stuff
Starbeamrainbowlabs
@sbrl
that would be a combinatory explosion
In this case then, might be best to avoid localising numbers
Seth
@sethi:matrix.org
[m]
(Also accomodates custom locales, if the user is a weirdo and does custom stuff.)
Starbeamrainbowlabs
@sbrl
for dates, use the ISO/RFC standards where possible
e.g. YYYY-MM-DD
Seth
@sethi:matrix.org
[m]

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.

Starbeamrainbowlabs
@sbrl
Great points. Do we have a dedicated issue open about the problem?
Would be great to document the arguments for future reference
Seth
@sethi:matrix.org
[m]
We don't have one at the moment, just that discussion.
I can try summarize the discussion on GitHub and here in an issue later tonight
Starbeamrainbowlabs
@sbrl
:+1:
CleanMachine1
@CleanMachine1

tldr-pages/tldr#6142

Has an owner sent the invitation?

Starbeamrainbowlabs
@sbrl
invite sent @CleanMachine1
bl-ue
@bl-ue
sorry @waldyrious for pinging you on GH again.
What do you think about #6146 ?
It's about removing :) from CONTRIBUTING.md
Around here:
...

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>.

...
Team, can we get approvals on #5988 so we can merge? General consensus is that it's been open long enough.
Starbeamrainbowlabs
@sbrl
Commented on #6146
waldyrious
@waldyrious:matrix.org
[m]
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
@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...
Starbeamrainbowlabs
@sbrl
That doesn't mean to say that the emoji can't echo the sentiment of the community as a whole
waldyrious
@waldyrious:matrix.org
[m]
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.
2 replies
bl-ue
@bl-ue
Well that's fine -- if the consensus is to keep it, let's keep it! I explicitly said that it's open for suggestions :)
Starbeamrainbowlabs
@sbrl
I agree with @ waldyrious here.
waldyrious
@waldyrious:matrix.org
[m]
That's great to hear. I wouldn't want a stronger uneasiness to sit with you just because others don't share it. Perhaps the difficulty in pinpointing it is precisely what signals that whatever the underlying issue is may not be causing a strong enough effect that would warrant changing the text. In any case, if you find a way to express it more clearly, I'm sure we'd all be open to reconsider.
bl-ue
@bl-ue
Thank you -- if I determine it, I'll post it here 🙂
Seth
@sethi:matrix.org
[m]

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.

Sorry it's a little long-winded. ^-^'
Starbeamrainbowlabs
@sbrl
Great writeup :+1:
Left my opinion after reading it in a comment
bl-ue
@bl-ue
Invite? #6149
Starbeamrainbowlabs
@sbrl
Invite sent :fireworks: