Merge pull request #1951 from jplag/feature/wiki-overhaul

Improve Wiki

docs/1.-How-to-Use-JPlag.md

@@ -6,8 +6,8 @@ JPlag can be used via the Command Line Interface by executing the JAR file.
 Example: `java -jar jplag.jar path/to/the/submissions`
 
 The language can either be set with the -l parameter or as a subcommand. If both a subcommand and the -l option are specified, the subcommand will take priority.
-When using the subcommand language specific arguments can be set.
-A list of language specific options can be obtained by requesting the help page of a subcommand (e.g. "jplag java -h").
+When using the subcommand, language-specific arguments can be set.
+A list of language-specific options can be obtained by requesting the help page of a subcommand (e.g., "jplag java -h").
 
 The following arguments can be used to control JPlag:
 ```
@@ -86,7 +86,7 @@ Subcommands (supported languages):
 *Note that the [legacy CLI](https://github.com/jplag/jplag/blob/legacy/README.md) is varying slightly.*
 
 ## Using JPlag programmatically
-The new API makes it easy to integrate JPlag's plagiarism detection into external Java projects.
+The API makes it easy to integrate JPlag's plagiarism detection into external Java projects.
 
 **Example:**
 
@@ -110,24 +110,24 @@ try {
 
 ## Report File Generation
 
-After a JPlag run a zipped result report is automatically created.
+After a JPlag run, a zipped result report is automatically created.
 The target location of the report can be specified with the `-r` flag.
 
 If the `-r` is not specified, the location defaults `result.zip`. Specifying the `-r` flag with a path `/path/to/desiredFolder` results in the report being created as `/path/to/desiredFolder.zip`.
 
-Unless there is an error during the zipping process, the report will always be zipped. If the zipping process fails, the report will be available as unzipped under the specified location.
+The report will always be zipped unless there is an error during the zipping process. If the zipping process fails, the report will be available in an unzipped version under the specified location.
 
 ## Viewing Reports
 
-The newest version of the report viewer is always accessible at https://jplag.github.io/JPlag/. Simply drop your `result.zip` folder on the page to start inspecting the results of your JPlag run. Your submissions will neither be uploaded to a server nor stored permanently. They are saved in the application as long as you view them. Once you refresh the page, all information will be erased.
+The newest version of the report viewer is always accessible at https://jplag.github.io/JPlag/. Drop your `result.zip` folder on the page to start inspecting the results of your JPlag run. Your submissions will neither be uploaded to a server nor stored permanently. They are saved in the application as long as you view them. Once you refresh the page, all information will be erased.
 
 
 ## Basic Concepts
 
 This section explains some fundamental concepts about JPlag that make it easier to understand and use.
 
 * **Root directory:** This is the directory in which JPlag will scan for submissions.
-* **Submissions:** Submissions contain the source code that JPlag will parse and compare. They have to be direct children of the root directory and can either be single files or directories.
+* **Submissions:** Submissions contain the source code JPlag will parse and compare. They have to be direct children of the root directory and can either be single files or directories.
 
 ### Single-file submissions
 
@@ -140,7 +140,7 @@ This section explains some fundamental concepts about JPlag that make it easier
 
 ### Directory submissions
 
-JPlag will read submission directories recursively, so they can contain multiple (nested) source code files.
+JPlag will read submission directories recursively, thus they can contain multiple (nested) source code files.
 
 ```
 /path/to/root-directory
@@ -155,7 +155,7 @@ JPlag will read submission directories recursively, so they can contain multiple
         └── Utils.java
 ```
 
-If you want JPlag to scan only one specific subdirectory of the submissions for source code files (e.g. `src`), can configure that with the argument `-S`:
+If you want JPlag to scan only one specific subdirectory of the submissions for source code files (e.g., `src`), you can configure that with the argument `-s`:
 
 ```
 /path/to/root-directory
@@ -173,7 +173,7 @@ If you want JPlag to scan only one specific subdirectory of the submissions for
 
 ### Base Code
 
-The base code is a special kind of submission. It is the template that all other submissions are based on. JPlag will ignore all matches between two submissions, where the matches are also part of the base code. Like any other submission, the base code has to be a single file or directory in the root directory.
+The base code is a special kind of submission. It is the template that all other submissions are based on. JPlag will ignore all matches between two submissions where the matches are also part of the base code. Like any other submission, the base code has to be a single file or directory in the root directory.
 
 ```
 /path/to/root-directory
@@ -186,7 +186,7 @@ The base code is a special kind of submission. It is the template that all other
     └── Solution.java
 ```
 
-In this example, students have to solve a given problem by implementing the `run` method in the template below. Because they are not supposed to modify the `main` function, it will be identical for each student. 
+In this example, students must solve a problem by implementing the `run` method in the template below. Because they are not supposed to modify the `main` function, it will be identical for each student. 
 
 ```java
 // BaseCode/Solution.java
@@ -204,15 +204,15 @@ public class Solution {
 }
 ```
 
-To prevent JPlag from detecting similarities in the `main` function (and other parts of the template), we can instruct JPlag to ignore matches with the given base code by providing the `--bc=<base-code-name>` option. 
+To prevent JPlag from detecting similarities in the `main` function (and other parts of the template), we can instruct JPlag to ignore matches with the given base code by providing the `-bc=<base-code-name>` option. 
 The `<base-code-name>` in the example above is `BaseCode`.
 
 ### Multiple Root Directories
-* You can run JPlag with multiple root directories, JPlag compares submissions from all of them
+* You can run JPlag with multiple root directories; JPlag compares submissions from all of them
 * JPlag distinguishes between old and new root directories
 ** Submissions in new root directories are checked amongst themselves and against submissions from other root directories
 ** Submissions in old root directories are only checked against submissions from other new root directories
-* You need at least one new root directory to run JPlag
+* You need at least one (new) root directory to run JPlag
 
 This allows you to check submissions against those of previous years:
 ```

docs/2.-Supported-Languages.md

@@ -1,11 +1,11 @@
-JPlag currently supports Java, C, C++, C#, Go, Kotlin, Python, R, Rust, Scala, Swift, and Scheme. Additionally, it has primitive support for text and prototypical support for EMF metamodels. A detailed list, including the supported language versions can be found in the [project readme](https://github.com/jplag/JPlag/blob/main/README.md#supported-languages).
+JPlag currently supports Java, C, C++, C#, Go, Kotlin, Python, R, Rust, Scala, Swift, Javascript, Typescript, LLVM IR and Scheme. Additionally, it has primitive support for text and prototypical support for EMF metamodels. A detailed list, including the supported language versions, can be found in the [project readme](https://github.com/jplag/JPlag/blob/main/README.md#supported-languages).
 
-The language modules differ in their maturity due to their age and different usage frequencies.
+The language modules differ in maturity due to their age and differing usage frequencies.
 Thus, each frontend has a state label:
-- `mature`: This module is tried and tested, as well as up to date with a current language version.
-- `beta`: This module is relatively new and up to date. However, it is not as well tested. **Feedback welcome!**
-- `alpha`: This module is very new and not yet finished. Use with caution! 
+- `mature`: This module is tried and tested and is (somewhat) up to date with a current language version.
+- `beta`: This module is relatively new and (somewhat) up to date. However, it has not been tested as well. **Feedback welcome!**
+- `alpha`: This module is very new and has not yet been finished. Use with caution! 
 - `legacy`: This module is from JPlag legacy (pre-v3.0.0) and may only support outdated language versions. It needs an update.
-- `unknown`: It is very much unclear in which state this module is.
+- `unknown`: It is very unclear which state this module is in.
 
 All language modules can be found [here](https://github.com/jplag/JPlag/tree/master/languages).

docs/3.-Contributing-to-JPlag.md

@@ -1,27 +1,28 @@
 We're happy to incorporate all improvements to JPlag into this codebase. Feel free to fork the project and send pull requests.
 If you are new to JPlag, maybe check the [good first issues](https://github.com/jplag/jplag/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22).
 
-Please try to make well-documented and clear structured submissions:
+Please try to make well-documented and clearly structured submissions:
 * All artifacts (code, comments...) should be in English
 * Please avoid abbreviations!
 * Make use of JavaDoc to document classes and public methods
 * We provide a [formatter configuration](https://github.com/jplag/JPlag/blob/master/formatter.xml), which is enforced by spotless
     * Eclipse/IntelliJ users can use it directly
     * It can always be applied via maven with `mvn spotless:apply`
 * Use well-explained pull requests to propose your features
-* When re-using code from other projects mark them accordingly and make sure their license allows the re-use
+* When re-using code from other projects, mark them accordingly and make sure their license allows the re-use
 * Your changes should always improve the code quality of the codebase, especially when working on older components
-* Your git messages should be concise but more importantly descriptive
+* Your git messages should be concise but, more importantly, descriptive
 * Ensure your git history is clean, or else your PR may get squashed while merging
+* When creating a PR, make sure to provide a detailed description of you changes and what purpose they serve
 
 ## Building from sources 
 1. Download or clone the code from this repository.
 2. Run `mvn clean package` from the root of the repository to compile and build all submodules.
-   Run `mvn clean package assembly:single` instead if you need the full jar which includes all dependencies.
+   Run `mvn clean package assembly:single` instead if you need the full jar, which includes all dependencies.
 5. You will find the generated JARs in the subdirectory `jplag.cli/target`.
 
 ### Git hooks
 
-The repository contains a pre-commit hook, that prevents commits if fail spotless.
+The repository contains a pre-commit hook that prevents commits if they fail spotless.
 To set up the hooks, call `git config --local core.hooksPath gitHooks/hooks` once within your local repository.