Thank you for considering contributing to LTEX. There are many ways to do so:
- You can report bugs to help make LTEX better.
- You can request features to make LTEX more powerful.
- You can contribute code to accelerate the pace of LTEX's development.
- You can test pre-release versions to help find bugs before they affect thousands of users.
- You can edit the documentation to make LTEX easier to use.
- You can translate the user interface into your mother tongue to make LTEX more accessible.
If you like LTEX, but are not able to contribute in any of these ways, there are still some quick and simple alternatives to show your gratitude:
- You can star the repository on GitHub.
- You can write a positive review of vscode-ltex on the Visual Studio Marketplace or on Open VSX.
- Make sure that your issue is really an LTEX bug.
- Make sure that your issue can neither be found in the list of known issues below nor in the list of all open and closed GitHub issues.
- Create a minimal example document for which the bug occurs. To do so, take your original document, for which the bug occurs, and delete roughly half of it. If the bug does not occur anymore, undo the deletion and delete the other half instead. If the bug occurs, repeat by deleting half of the remaining half etc., until you arrive at a very small document, for which the bug still occurs. This is the minimal example document.
- Create a minimal example configuration for which the bug occurs. To do so, proceed as for the minimal example document, except that you delete half of your settings.
- Set the setting
"ltex.trace.server": "verbose"
. - Open an issue on GitHub, select the
Bug Report
template, and fill in as much info as you can. This will help us reproduce the issue.
Important: Please follow the issue template. Issues that don't follow the template or that don't contain the vital information requested in the template (especially minimal example document and settings) may be immediately closed as invalid.
- The LaTeX parser is not perfect. False positives are sometimes reported as errors. However, it is impossible to fully parse LaTeX's output without compiling the source. This follows from the Turing-completeness of TeX and the halting problem.
- Initial checking might take a while (up to two minutes), depending on the length of the document. This is a limitation of LanguageTool.
- Make sure that your feature is actually about LTEX (not about LanguageTool, for example).
- Make sure that your feature is not in the list of all open and closed GitHub issues.
- Open an issue on GitHub and select the
Feature Request
template. - Enter a summary of the feature in the title field and fill out the template in the description field. Fill in as much info as you can. Using actual real-world examples that explain why you and many other users would benefit from the feature increases the request's chances of being implemented.
Important: Please follow the issue template. Issues that don't follow the template or that don't contain vital information requested in the template may be immediately closed as invalid.
As explained in the FAQ, LTEX consists of two components: vscode-ltex and ltex-ls. This guide is only about the ltex-ls part. If you want to change vscode-ltex as well, be sure to read and follow the contribution guidelines of ltex-ls.
- Install VS Code, Git, and Apache Maven.
- Fork ltex-ls on GitHub.
- Clone the fork:
git clone https://github.com/<YOUR_USERNAME>/ltex-ls.git
- Build the project:
cd ltex-ls && python tools/createCompletionLists.py && mvn verify
- It's recommended to use IntelliJ IDEA to debug ltex-ls.
- Set up the project.
- Implement your changes.
- Use commit messages in the following form: First line in imperative, first letter upper case, no trailing period, maximum 50 characters. Second line is blank. Additional information (if any) is in third and following lines. If the change is related to an issue, use
See #1234.
orFixes #1234.
as a separate final paragraph. - Check if the project builds:
mvn verify
. - Open a pull request with the
develop
branch as the target branch. - If the GitHub Actions CI reports any errors, fix them.
- Wait until a maintainer reviews your PR.
You can help find bugs before they affect thousands of LTEX users by testing pre-releases.
- Check whether a pre-release is available on the releases pages of ltex-ls (pre-releases, if there are any, are at the top of the page).
- Download and extract the pre-release.
- Check if all currently listed changes in the changelog on the
develop
branch work as announced.
The availability of pre-releases varies. Pre-releases are only available if a pre-release tag (a tag with the name of a version number with a dash in it, e.g., 8.0.0-alpha.3
) has been pushed to the repository. Pre-releases are only available for a limited time; they will be deleted once the regular release has been taken place.
Of course, pre-releases are not for productive work, they even may be harmful.
You can improve the documentation:
- Check whether the page you want to edit is listed in the table below.
- If yes, then follow the corresponding link to the source.
- If no, then click on “Edit me on GitHub” at the bottom of the page you want to edit.
- Implement your changes.
- Use commit messages in the form as mentioned above.
- Open a pull request with the
develop
branch as the target branch. - If the GitHub Actions CI reports any errors, fix them.
- Wait until a maintainer reviews your PR.
Page | Sources |
---|---|
Settings | package.json , package.nls.json |
Code of Conduct | CODE_OF_CONDUCT.md |
ltex-ls → Changelog | ltex-ls/changelog.xml |
ltex-ls → Contributing | ltex-ls/CONTRIBUTING.md |
The user interface of LTEX is currently available in the following languages:
- English
- German
You're welcome to help extend this list. To do so, only fluent proficiency (CEFR C1-level) in the target language is required, no programming skills.
- Duplicate
src/main/resources/LtexLsMessagesBundle_de.properties
, replacingde
with the ISO 639-1 language code of your language. - For each of the entries in the duplicated file: Look up the English original of the entry in the corresponding English file, and replace the German translation with the translation into your language.
- Use commit messages in the form as mentioned above.
- Open a pull request with the
develop
branch as the target branch. - If the GitHub Actions CI reports any errors, fix them.
- Wait until a maintainer reviews your PR.
Of course, it's also possible to duplicate the English language files instead, but you only need to translate the strings that are shown in the user interface (the other ones are for logging, debugging, etc.). The German language files already provide the correct subset of strings.