Internationalization and localization (i18n) play a crucial role in the spread of open source software across boundries, for the lack of documentation and user interface translations to a given language can be a huge barrier for many users.
If you're native language is other than English, you might consider helping with translations via one of the following ...
Highlight GUI i18n
You could help with the translation of Highlight GUI user interface. Highlight GUI use Qt 5, so you'll need the Qt Linguist tool (which is part of the Qt distribution) to edit the *.ts files inside Highlight src/gui-qt/ folder:
You could fork the upstream Highlight repository and start a new Highlight Wiki in your native language, or any other language you're fluent with. You have total freedom to translate, reuse and otherwise adapt the contents of this Wiki.
Over the years different people contributed new syntax definitions to Highlight, which now supports over 224 languages and markup syntaxes. Some syntaxes could be improved, others might need to be updated to reflect the current status of a given language, and some languages don't have a syntax yet.
If you're fluent in a given programming language or markup syntax, you might consider contributing by:
Updating current syntaxes
Adding new syntaxes
This Wiki provides useful information on how work with Hihglight syntax definitions, so it should be a good starting point. Creating syntaxes is not as difficoult as it might sound, but it requires knowledge of the language being defined.
For the same reason, the project is always in need of people willing to take on maintainance of specific language definitions by people who master that language. If you are commmited to a specific language, you could consider becoming the maintainer of its Highlight langDef.
The goal of the project is to provide a source code example for every language natively supported by Highlight, so that end users can test how themes are rendered which language, as well as being able to check how well each langDef highlights the code.
Building examples that are elegant, syntax rich and meaningful at the same time is not an easy task, and defintely on that require knowldege of tha language or markup syntax. So this is an area where contributions are much needed and appreciated.
You'll find more details about the examples project in the README file inside its folder.
Highlight Test Suite
The test suite is a recent project that followed the new syntax testing feature introduced in Highlight v3.45:
The goal of the project is to create a collection of tests for all the languages supported by Highlight, in order to:
Uncover and annotate edge cases that are not handled correctly by a landDef.
Detected breaking changes while editing a landDef.
Test a langDef against new features of a language when the latter is updated.
Developers can also use this project to test syntax developement in local branches before submitting new/updated langDefs to Highlight repository. This offers a convenient work approach, especially for language definitions which fail some tests and need updating, where the developer can run the existing test files against his/her tweaked langDef (using the --config-file= option inside a customized test script).
The idea behind the project is that by sharing with community the syntax tests created while working on our langDefs, we'll make it easier for other users to take the work from where we left it. The test suite is also useful to point out missing features in language definitions, and adding tests to show weaknesses ina langDef acts as reminder of things to be done.
What Could I Contribute?
For a start, the least you can do is show your appreciation by starring on GitLab and GitHub the Highlight project, this Wiki and related projects, thus helping them gain visibility and status:
By contributing contents to this Wiki you understand and implicitly accept that others might reuse these contents in other projects without restrictions.
I've willingly avoided to attach any license and strings to these contents because of the intricacy of licenses relating to documentation. I'd rather openly state that people you should free to reuses these contents as they deem fit. The purpose of the Wiki is to spread knowledge on Highlight and its usage, and whoever is doing so is helping this project too.
Being a project open to users' contributions, where pages are intended to be edited over again by different people, there is not point in claiming any authorship either, except when quoting others.
The philosophy behind this Wiki is very well summarized at this link:
you should visit the above link before contributing to the Wiki.
If you are not at ease with the idea that your contributed contents will not carry your authorship, or that they might be reused and edited by others, without them asking your permission and/or crediting you for them, then this Wiki might not be the right thing for you, and you should consider starting a documentation project of your own, using a license that safeguards your work as you see it fit.
Keep It Markdown
GitHub projects' Wiki can host pages in a variety of markup syntaxes. For the sake of consistency an easier maintainance, I would like all pages in this Wiki to be in GitHub flavoured markdown (aka "GFM"), which is a very popular markdown variant as well as GitHub's native markup syntax.
If you're more confortable writing in other markup syntaxes, you could use pandoc to convert from your favourite markup syntax to GFM:
These HTML comment tags are used by a Sublime Text 3 plugin, called MarkdownTOC, to automagically generated a GitHub compliant Table of Content when saving the document.
So, please don't touch the TOC's comments tags. If you don't have Sublime Text, don't worry aobut the TOC contents: when I'll see that a page was changed I'll take car of updating its TOC. Any manual changes to the TOC will be overwritten and lost every time MarkdownTOC regenerates a new TOC from scratch.
For maintainance conveniency, some Wiki pages are auto-generated by Bash scripts via heredoc and direct queries to Highlight command line tool:
You should not edit those pages directly, as all changes would be lost when they are updated by their scripts. If you want to improve their contents, edit their generator script heredoc template instead.
EOL NOTE — All script-generated pages must use Unix style LF EOL, whereas normally markdown files are set to native EOL in .giattributes. The reason for this is to allow running the scripts under Bash for Windows, where Highlight CLI output redirection will introduce CRLF EOLs in the generated document, along with LF EOLs generated by the script, thus preventing Git from commiting it.
To enforce LF EOL, All page-generating scripts invoke the dos2unix command on the output file after generating it. The Wiki .giattributes contains exceptions rules targetting the auto-generated files, to enforce Unix EOL on them.