It's my TlDr project aiming to replace TlDr and provide clear and standardized syntax for everything. Here is syntax description. Can u provide support for both projects? For instance let user chose what project pages they want to explore: TlDr or Better TlDr ones.

Recently (today) I've created a new TlDr project to formalize programs CLI via JSON schemas. It means that we will be able to check CLI usage in the future automatically not relying on parsing man pages. Also it means that it will be possible to easily know what subcommands and options are supported and how they must be used. To tell a long story short I suggest (several weeks later when everything will be ready for it) to implement ability to chose by regex what options to show as short and what as long. For instance to show all options starting with a as short, and others as long.

The search parameters are getting cleared automatically with an incomplete suggestion and it isn't allowing us to search for pages.

Test environment: PWA (Android)

It would be cool to have the actual Sun Microsystems icon there instead of the screen favicon.

Hello there,

I am an educator and I have always been very passionate about this project. Hence as a first issue I would like to take a moment to thank everyone who played a part in bringing this concept to life. It has changed the lives of hundreds of my students. It namely made them see that despite the lengthy manpages, the actual use cases are often tangible, easy-to-understand and can be adapted with little effort.

I just now tried to look up package manager commands like apk for alpine and apt-get for most Linux systems and I was surprised not to find anything. I also tried apt-get-update as the case with git commands.

Did I fail to find the TLDR pages? And if these commands were excluded from the project, then may I ask why?

NOTE: This is a content-related issue.

I'd like to add TLDR to my browser as a search engine which would require an endpoint to navigate to. I could do something like https://tldr.inbrowser.app/pages/common/%s, but that wouldn't work for everything.

tldr.inbrowser.app announces an opensearch plugin via link header, but the referenced opensearch.xml returns a 404.

As the file exists in this repo, I guess it's some deployment issue.

When a page/translation doesn't exist no action takes place currently, maybe a message can be displayed informing the user the page/translation for the English page doesn't exist and tldr repo can be linked for contributing it.

In our Node client we specify this when a page doesn't exist:

> tldr github
`github` documentation is not available.
If you want to contribute it, feel free to send a pull request to: https://github.com/tldr-pages/tldr

I tried to install https://tldr.inbrowser.app/ as a search engine, using Firefox context menu.
But unfortunately this did not work and failed with following message:

Invalid Format
Firefox could not install the search engine from: https://tldr.inbrowser.app/opensearch.xml

I am running Firefox 102.9.0esr on Gentoo GNU/Linux.

Perhaps related to #12

Add a customizable syntax highlighting for generic placeholders:

• strings:
  • default: highlight quotes and content inside them with orange color
  • settings: quotes and content color can be changed just together
• numbers
  • default: highlight integers and floats in cyan color
  • settings: integer and float colors can be changed just together
• ranges
  • default:
    • highlight borders (integer or float numbers) in cyan
    • highlight -infinity and infinity keywords in blue
    • highlight .. in light cyan
  • settings: can be customized for 3 different aspects separately
• path placeholders
  • default: highlight paths in red, while highlighting their separators in dark red
  • settings: can be customized for 3 different aspects separately
• placeholders with ellipsis
  • defaults:
    • all defaults listed above applies for ellipsis placeholders
    • ... is highlighted as gray
  • settings: only changing ... color is supported, all other settings are being set for concrete placeholder types

Hi there!

Many thanks for developing this project. I've written a Dockerfile to create a container image and self-host the web application.

Since some changes to the Git repository, I get the following type-check error while running npm run download:tldr-pages && npm run build:sitemap && run-p type-check build-only:

src/data/tldr-pages/page/zip/zipLib/getText.ts(5,22): error TS2722: Cannot invoke an object which is possibly 'undefined'

Here is the relevant log from docker build ... (Dockerfile):

 => [builder 4/5] RUN npm install --progress                                                                                                                                  61.0s
 => ERROR [builder 5/5] RUN npm run build                                                                                                                                     14.9s
------
 > [builder 5/5] RUN npm run build:
0.724 
0.724 > [email protected] build
0.724 > npm run download:tldr-pages && npm run build:sitemap && run-p type-check build-only
0.724 
0.942 
0.942 > [email protected] download:tldr-pages
0.942 > wget -O public/tldr-pages.zip https://github.com/tldr-pages/tldr/archive/refs/heads/main.zip
0.942 
0.968 Connecting to github.com (140.82.121.4:443)
1.247 Connecting to codeload.github.com (140.82.121.9:443)
1.450 saving to 'public/tldr-pages.zip'
2.209 tldr-pages.zip        47% |***************                 | 3379k  0:00:01 ETA
2.881 tldr-pages.zip       100% |********************************| 7138k  0:00:00 ETA
2.881 'public/tldr-pages.zip' saved
3.108 
3.108 > [email protected] build:sitemap
3.108 > node scripts/build-sitemap.js
3.108 
3.414 Sitemap page urls count: 15933
3.417 Writing sitemap.xml
3.781 
3.781 > [email protected] type-check
3.781 > vue-tsc --noEmit -p tsconfig.vitest.json --composite false
3.781 
3.783 
3.783 > [email protected] build-only
3.783 > vite build
3.783 
4.288 vite v4.5.2 building for production...
4.351 transforming...
14.72 src/data/tldr-pages/page/zip/zipLib/getText.ts(5,22): error TS2722: Cannot invoke an object which is possibly 'undefined'.
14.85 ERROR: "type-check" exited with 2.
------
Dockerfile:15
--------------------
  13 |     RUN npm install --progress
  14 |     # Build to ./dist/
  15 | >>> RUN npm run build
  16 |     
  17 |     FROM nginx:alpine as webserver
--------------------

If this is too far off topic and your builds work, please don't put too much effort into this issue. But I thought that maybe this points you to some relevant error/bug in the code.

The search box is constantly displaying changing suggestions on what to search for.
I think this is a distraction and I wanted to suggest either removing it or at least offering a setting to disable it.

I am not sure how you feel about it, but I have often trouble focusing when there is anything constantly moving in my peripheral vision.

I know I can just type something into that box as a workaround, but well anyway I wanted to open such an issue and should you agree I could try to open a PR to make this suggestions an option to be displayed.

Hi, this project is really awesome, thanks so much for creating it!

I noticed that there are quite a few accessibility issues with the web UI. The following is a list of things I've noticed while using it. This is likely not a complete list as I did not run any automated a11y tests or do manual a11y testing using various screen reader software which you may want to employ for more thorough testing for a complete list of a11y issues. These were mainly ones I noticed from using the site and poking around the DOM using dev tools.

• there are multiple <h1> tags (in the <header> and in the <main>), there should only be one h1 on the page. I suggest making the one in the main section an <h2>.

• the search box input should be wrapped in a <form> with role="search" or have the text input have type="search".

• the search box does not have a label associated with it, so it lacks an accessible name, thus its purpose will not be clear to users of assistive tech such as screen readers.

• the list of autocomplete results does not appear to be associated with the searchbox via ARIA which means someone using a screen reader will have a difficult or impossible time using them. There are patterns for implementing this such as this one and this one

• the gear icon button does not have an accessible name. This can be added via the aria-label attribute.

• the tooltip / popup on the gear icon next to the search box is only accessible via mouseover. Anything that appears visually via mouseover should also appear via focus. This UI element might be better implemented as a toggle tip (vs. a tooltip) where someone clicks it to reveal it. This would enable a keyboard "click" interaction (via enter or space key) to reveal the popup and place focus within it which would be ideal since it contains form elements that control settings. Alternatively move these form elements out of the tooltip and put them adjacent to the search box so that they're not hidden by a mouseover/focus/click interaction.

• the bulleted list in the <main> area is not structured well (example page). Each bullet point (<li>) is within its own <ul> element, and the code snippet is in a <p> tag outside of the <ul>. This structure doesn't take advantage of unordered lists in HTML and could be improved by wrapping all bullet points in the same <ul> and including the code block within the same <li> as its description. Or use a description list (<dl>) to associate the descriptive text (key <dt>) with the code snippet (value <dd>).

• the UI appears to be created as an SPA and dynamically loads content on the page vs. causing a page reload after searching. If this is the case then consider using a ARIA live region to announce to screen readers that content has been updated on the page when this occurs.

Fixing these issues will help make the project more inclusive and accessible to folks with disabilities, I strongly recommend that they be addressed. Something like one in five people have a disability of some kind, including people who use the CLI, let's not prevent them from benefiting from this project and the knowledge it contains.