# Diciotech: a collaborative Portuguese tech dictionary built on Jekyll

> Diciotech is an open source online dictionary of technology terms, written in Portuguese and built as a Jekyll site with JSON data files, a search index and a translation layer. It suits contributors who want to teach a concept in their own words, and it is the wrong tool if you need a glossary in English or a schema you can query.

**levxyca/diciotech** — O Diciotech é um dicionário tech online colaborativo e open source. Nossa missão é ajudar pessoas de todos os níveis a entenderem termos e conceitos relacionados à tecnologia de forma clara e simples.

- Repository: https://github.com/levxyca/diciotech
- Website: https://diciotech.netlify.app/
- Stars: 712 · Forks: 96
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/levxyca-diciotech

## A dictionary where the entries are the point, not the software

Diciotech is described as an online, collaborative and open source tech dictionary whose mission is to help people at every level understand technology terms and concepts in a clear and simple way. The build is HTML, SASS, JavaScript and Jekyll, and the site is published at a Netlify address.

What the project offers its readers is stated as a short list. You can learn new terms quickly and easily, you can search terms with smart suggestions and tolerance for typing mistakes, you can contribute to building a tech learning community, and you can improve your technical skills in a collaborative way.

That last pair is the interesting part for anyone evaluating the project. This is not primarily a software tool that happens to hold a glossary. It is a written reference whose production mechanism is a static site, and the contribution is writing the definition. The GitHub Discussions link in the project description is where that conversation happens, which suggests a small community around a specific kind of work.

The stated audience is broad on purpose, people of all levels, and the medium is Portuguese. The topic list on the repository includes i18n, jekyll, multilanguage and multiple-languages, so the site is built with translation in mind from the start rather than having an English version bolted on later. The primary language of the code is JavaScript, and the licence is GPL-3.0, which is a deliberate choice for a collaborative corpus where the content is the valuable part.

## Content in data files, pages generated by Jekyll

The repository layout explains the architecture better than any description would. This is a Jekyll site in the conventional shape: a _config.yml at the root holds the site configuration, _layouts/ and _pages/ hold the templates and routes, _sass/ holds the styles, _scripts/ holds the client-side JavaScript, and assets/ holds images and other static files, including the brand logo and the site screenshot referenced from the project readme.

The content directories are the interesting part, because there are two of them and they are named for their format. _data/ holds Jekyll data files, which is where structured content lives and where a term entry would be added, and _json/ holds JSON output. Having both suggests a pipeline: entries are written in one place and a JSON artefact is produced for the other.

That pipeline is visible in the scripts. format_data.py sits at the repository root as the Python side of the transformation, and run_on_code_changed.sh and run_on_data_changed.sh are the two trigger scripts, one reacting to a change in code and one reacting to a change in data. Whatever a contributor edits, the same two steps run, which is the part that keeps a hand-maintained JSON index from drifting away from the source entries.

The root also has a Gemfile and a Gemfile.lock, which is how a Jekyll site pins its Ruby dependencies, and a package-lock.json next to a package.json that declares only two development dependencies, prettier and the Shopify plugin for formatting Liquid templates:

```json
{
  "devDependencies": {
    "@shopify/prettier-plugin-liquid": "^1.6.3",
    "prettier": "^3.3.3"
  }
}
```

The .pre-commit-config.yaml, .prettierrc and .prettierignore files say the same thing from the tooling side: formatting is enforced before a commit lands, and Liquid templates are formatted with the plugin because they are not plain HTML. There is a .devcontainer/ directory as well, so a contributor can work in a containerised environment rather than matching the local Ruby and Node versions by hand.

## Search with suggestions and typo tolerance

The search behaviour is called out separately from the learning goal, and it is the piece most visible to a visitor. Terms can be found with intelligent suggestions and tolerance for typing errors, which for a dictionary means a reader who half-remembers a word still lands on the right entry.

The implementation of that is the JavaScript under _scripts/, and the index it searches is the JSON under _json/. That pairing explains why there is a Python script and two change-triggered shell scripts in the root: the entries live in the data files, the search index is a JSON file, and something has to keep the second in step with the first. The two shell scripts exist to make that step automatic rather than a manual step that contributors forget.

A web manifest file, diciotech.webmanifest, sits in the root as well, which is what lets the site be installed to a phone home screen and opened like an application.

The practical consequence for a contributor is that a new term is a data change, not a code change. That is what makes the project approachable for someone whose strength is explaining a concept rather than writing JavaScript. It is also what makes the tooling matter: if the index is generated, the failure mode of a bad contribution is a broken search rather than a broken page, and the pre-commit and formatting configuration is there to keep a large set of data files consistent.

## Four ways in, and a roadmap that says where it is going

The contribution paths are spelled out in the project readme and each one is a GitHub mechanism rather than a code convention, which is deliberate for a project whose contributors are not all developers.

A feature request goes through an issue template named feature_request.md, a bug report goes through a template named bug_report.md, and a pull request follows the standard GitHub flow. The fourth path is the lowest barrier of all: using the project and commenting with your experience. The project also points at the open source guide's article on how to contribute to open source, and at a separate article for anyone working on their first contribution.

Two documents do the explaining. CONTRIBUTING.md is said to cover all the ways to contribute, and ROADMAP.md exists so that people can keep track of how the project is meant to evolve. Having a roadmap in a repository of this size is a signal, since it means the maintainer has thought about direction rather than only about the current state of the site.

The contributor list is rendered from a graph service image, which is a small choice with a large effect on a collaborative project: the visible list of people who contributed is part of the front page, and it is generated rather than maintained by hand.

The repository also carries the .github/ directory, which is where the issue templates, the pull request template and the automation live, and the project topics include hacktoberfest, which is a further hint that the project expects a steady trickle of outside contributions rather than a small team working alone.

## Where the project stops short

The first limitation is language. The content is Portuguese, and although the topic list advertises multilanguage support and the site is built with translation in mind, the dictionary as it exists today is a Portuguese reference. A team that needs English definitions of the same terms is looking at a different project, or at a translation effort that has to be paid for.

The second is that a generated static site is a browsing experience, not a queryable database. The entries become JSON, which is a good format to consume programmatically, but the artifact is the site. There is no API, no search endpoint and no versioning of individual entries, so a tool that wanted to pull a definition would be scraping a site rather than calling an interface.

The third is the pace. The release tags are v1.0 on 2023-11-26, v1.1.0 on 2024-09-20 and v1.2.0 on 2025-01-06, which is a small project shipping minor versions a few times a year. The last push to the repository was on 2026-04-10, so treat any expectation of a weekly release rhythm as unfounded, and read the ROADMAP.md file rather than the tag list to judge what is likely to happen next.

The fourth is the tooling cost of the pipeline itself. Two trigger scripts, a Python formatter, Prettier with a Liquid plugin, a pre-commit configuration and a dev container are a lot of machinery for a dictionary. It buys consistency across many small data files, and it costs a contributor who just wants to add one entry a setup step. A fork that simply edited the data files by hand would be simpler and would drift.

## Conclusion

Diciotech fits a contributor who wants to write a clear, plain-language explanation of a technical term in Portuguese and see it published without touching application code, since the content lives in data files and the site is generated from them. It is the wrong choice if you need English definitions, a queryable term database rather than a browsable site, or a project with a predictable release cadence, because the newest tag is v1.2.0 from 2025-01-06 and the last push was on 2026-04-10. Before contributing, read CONTRIBUTING.md and ROADMAP.md, run the two change-triggered scripts in the repository root so the generated JSON stays in step with the sources, and check whether the term you want to add already exists in the data files rather than adding a duplicate entry.

## FAQ

### What is Diciotech and who is it for?

Diciotech is an open source, collaborative online dictionary of technology terms written in Portuguese, built with HTML, SASS, JavaScript and Jekyll. Its stated mission is to help people at every level understand technical terms and concepts clearly and simply.

### How do I add a term to Diciotech?

Term entries live as data in the _data/ directory, so adding one is a data change rather than a code change. The project readme points to CONTRIBUTING.md for the full set of ways to contribute, including issue templates for feature requests and bug reports and the standard pull request flow.

### How is the Diciotech site built and hosted?

It is a Jekyll site with a _config.yml, _layouts, _pages, _sass and _scripts directories, and it is published at a Netlify address. A Gemfile and Gemfile.lock pin the Ruby dependencies, and a .devcontainer/ directory is provided for containerised development.

### What licence does Diciotech use?

GPL-3.0, with the licence file in the repository root.

### How often is Diciotech updated?

The tagged releases are v1.0 from 2023-11-26, v1.1.0 from 2024-09-20 and v1.2.0 from 2025-01-06, and the last push to the repository was on 2026-04-10.

## Sources

- [levxyca/diciotech on GitHub](https://github.com/levxyca/diciotech)
- [License: GPL-3.0](https://github.com/levxyca/diciotech/blob/main/LICENSE)
- [Project website](https://diciotech.netlify.app/)
- [README](https://github.com/levxyca/diciotech/blob/main/README.md)
- [Releases](https://github.com/levxyca/diciotech/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/levxyca-diciotech