[FEATURE]: Add a text file containing all the words for dictionary based projects (auto-complete, auto-suggestions)

[d093w1z]

Is this a unique feature/idea?

• I have checked "open" AND "closed" issues and this is not a duplicate

Is your feature request related to a problem/unavailable functionality? Please describe.

There isn't a simple list of words of our dictionary that can be used by anyone for a dictionary/word based project.
I use Obsidian for my note-taking and needed a jargon word-list.

Proposed Solution

Add a text file that is accessible directly to anyone that contains all the words in a simple '.txt' format.
I believe jargon words are rarely ever used for suggestive help in text editors/ note taking apps. This feature would help people use our dictionary as a word-list for suggestions.
This feature is something similar to dwyl/english-words but using our dictionary.

Screenshots

No response

Do you want to work on this issue?

Yes

If "yes" to above, please explain how you would technically implement this

I propose a GitHub Actions script that is triggered whenever the directory contents of "src/content/dictionary" are changed.

This script will generate a list of the files in that directory and add it to a file called word-list.txt.

This will serve as a jargon word list.

This script will update the word list file and make a commit.

[babblebey]

Hey @d093w1z,

Thank you for the creating this ticket, I see the thoughts behind this and it sounds great. This is a certain direction that I'd actually like this project head to.... i.e. ability to be able to consume the resources in other projects... hence the reason we have an endpoint where you have access to all words (with their meaning) available for the public.

All Words Endpoint: https://www.jargons.dev/api/v1/browse

This I believe is better approach that can be easily maintained and integrated with other project, than using the txt based one which my introduce some maintenance overheads.

This endpoint by the way, I believe It can use some improvement/optimization i.e. statically generate the content at build time to a JSON endpoint - https://docs.astro.build/en/guides/endpoints/#static-file-endpoints... Sounds good to have a word-list.json than it to use a word-list.txt, don't you think!? 😉

Please let me know whether this helps.

[d093w1z]

Yes, it makes complete sense.

I see how the approach of a static file endpoint will be the best option for this.

I will implement the API endpoint for this and submit a PR.
Please let me know if I can help with this!

[babblebey]

By all means please do..

You can follow the already established patter to gather all words in the dictionary as seen in /api/v1/browse route which uses the Astro content collection

Introduce this as a new route at api/v1/words.json route.

PS: I just noticed that in the response for the current api/v1/browse endpoint, there's an intended property slug that should be present in the response but isn't... I can tell that the reason why that is the case is due to the latest convention in the Astro Content layer, where the slug property has now been replaced with the id.

Take note of this as you work on the new endpoint.... We will fix the api/v1/browse endpoint in a separate PR.

[babblebey]

By all means please open a PR... I will assign you this issue.

You can follow the already established patter to gather all words in the dictionary as seen in /api/v1/browse route which uses the Astro content collection

Introduce this as a new route at api/v1/words.json route.

PS: I just noticed that in the response for the current api/v1/browse endpoint, there's an intended property slug that should be present in the response but isn't... I can tell that the reason why that is the case is due to the latest convention in the Astro Content layer, where the slug property has now been replaced with the id, so word.slug should've been word.id in the computation at...

https://github.com/jargonsdev/jargons.dev/blob/main/src%2Fpages%2Fapi%2Fv1%2Fbrowse%2Findex.js#L15

Take note of this as you work on the new endpoint.... We will fix the api/v1/browse endpoint in a separate PR.