# OLD Style guide builder
{% hint style="info" %}
The style guide functionality was introduced in v5.29.0. It is now available to all paid users. Users with a self-hosted product version can create and manage their company style guides, including custom categories and rules. Other paid users can currently create and manage custom style guide rules through an API or admin panel.
In addition, all users have access to a predefined set of rules built on top of the style guide functionality. These rules support inclusive, respectful, and authentic language checks across multiple languages.
{% endhint %}
**Key features:**
1. Custom rules: With the Style Guide functionality, all paid users can create and manage their own linguistic rules and patterns. This ensures smooth and precise communication tailored to specific business requirements.
2. Custom categories: Users with a self-hosted product version can create and organize custom categories, enabling more advanced structuring of their company style guide.
3. Style check (predefined rule lists): We provide predefined sets of rules to address non-inclusive, profane, and non-authentic writing. These comprehensive rule sets help maintain a professional and respectful tone across written content. Users can control how detected issues are displayed directly from the UI, in line with the Style Guide rules.
This new feature is available for WProofreader for RTEs, the plugin for CKEditor 5, Web API, and the browser extension.
* [1. How to configure Custom guide functionality?](#styleguidefunctionalityv.1-or-release5.29.0.0-1.howtoconfigurecustomguidefunctionality)
* [1.1. Managing Custom guide functionality state for on-premise version 5.29.0.0+ via AppServerX.xml file (back-end)](#styleguidefunctionalityv.1-or-release5.29.0.0-1.1.managingcustomguidefunctionalitystateforon-premise)
* [1.2. Managing rules statuses for on-premise version 5.29.0.0+ via disabledRules.json file (back-end)](#styleguidefunctionalityv.1-or-release5.29.0.0-1.2.managingrulesstatusesforon-premiseversion5.29.0.0+)
* [1.3. Disabling specific rules or rules categories for cloud and on-premise version v.5.29.0.0 (client-side)](#styleguidefunctionalityv.1-or-release5.29.0.0-1.3.disablingspecificrulesorrulescategoriesforcloudand)
* [1.4. Using Web API to manage style guide feature for cloud and on-premise version v.5.29.0.0](#styleguidefunctionalityv.1-or-release5.29.0.0-1.4.usingwebapitomanagestyleguidefeatureforcloudandon)
* [2. Creating custom rules for on-premise clients v.5.29.0.0+](#styleguidefunctionalityv.1-or-release5.29.0.0-2.creatingcustomrulesforon-premiseclientsv.5.29.0.0+)
* [2.1. Limits and requirements](/v6.12.0/faq/technical/caching/can-we-control-the-cache-limit-is-it-configurable.md)
* [2.2. How to create custom rules?](#styleguidefunctionalityv.1-or-release5.29.0.0-2.2.howtocreatecustomrules)
## **1. How to configure Custom guide functionality?**
Cloud users have their text verified against a predefined set of WebSpellChecker-provided rules, which can be enabled or disabled individually or as a group. In addition, all paid users can create and manage custom style guide rules, currently available via API or the admin panel.
Users with a self-hosted version have extended capabilities, including full control over their Style Guide setup, with the ability to create and organize both custom rules and categories.
### **1.1. Managing Custom guide functionality state for on-premises version 5.29.0.0+ via AppServerX.xml file (back-end)**
Style Guide functionality is enabled by default. The found mistakes are highlighted with the yellow lines starting v.5.29.1.0. The folder with appropriate files for on-premises clients is located in the core AppServer directory:
**\\WebSpellChecker\AppServer\StyleGuide**
Starting with WebSpellChecker standalone version 5.29.0.0 you can manage the state of the Style Guide functionality follow the steps below:
1. Locate and open the **AppServerX.xml** configuration file for editing. By default, the file is located in \/AppServer/AppServerX.xml.
2. Before making any changes to the AppServerX.xml file, it is recommended to [stop AppServer](https://docs.webspellchecker.net/display/WebSpellCheckerServer55x/Main+AppServer+Commands#MainAppServerCommands-stopAppServerWindowsLinux2.StopAppServer).
3. Find a block with the needed language by language name or its shortcode. For example, American English
```
StyleGuide
```
4\. Change the value for **Enabled** state from true to **false**.
5\. Save the updated version of the **AppServerX.xml** file and [start AppServer](https://docs.webspellchecker.net/display/WebSpellCheckerServer55x/Main+AppServer+commands#MainAppServercommands-startAppServerWindowsLinux1.StartAppServer) to apply changes.
If you run WebSpellChecker on Docker, you can [create an updated image from a modified Docker container](https://github.com/WebSpellChecker/wproofreader-docker) to use it further.
### **1.2. Managing rules statuses for standalone version 5.29.0.0+ via disabledRules.json file (back-end)**
The WebSpellChecker on-premises clients with access to the internal software configuration can disable a particular Style Guide or grammar rule by using the ‘**disabledRules.json**’ configuration file, which is located by default in the root installation directory **\\WebSpellChecker\AppServer**
This is a regular JSON file (with comments supported) with two array values: ‘categories’ and ‘rules’, for the lists of category and rule IDs, respectively.
{% code title="disabledRules.json" %}
```json
{
"categories": [
// "WSC_CATEGORY_NAME",
// "COMPANY_CATEGORY_NAME"
],
"rules": [
// "WSC_1234567890",
"DATE_NEW_YEAR",
"OXFORD_SPELLING_NOUNS",
"OXFORD_SPELLING_ISE_VERBS",
"OXFORD_SPELLING_ADJECTIVES",
"OXFORD_SPELLING_ADVERBS",
"OXFORD_SPELLING_Z_NOT_S",
"OXFORD_SPELLING_GRAM"
]
}
```
{% endcode %}
As for the built-in ones, we have **several categories** of custom rules
* English: WSC\_GENDERED\_AND\_ABLEIST\_LANGUAGE, WSC\_RACE\_AND\_ETHNICITY\_INSULTS, WSC\_STRONG\_SWEAR\_LANGUAGE
* German: WSC\_FOREIGN\_WORDS WSC\_RACE\_AND\_ETHNICITY\_INSULTS WSC\_STRONG\_SWEAR\_LANGUAGE WSC\_ANGLICISM\_AND\_ALTERNATIVE
* Spanish: WSC\_RACE\_AND\_ETHNICITY\_INSULTS WSC\_STRONG\_SWEAR\_LANGUAGE WSC\_FOREIGN\_WORDS WSC\_ANGLICISM\_AND\_ALTERNATIVE
* French/ Canadian French: WSC\_RACE\_AND\_ETHNICITY\_INSULTS WSC\_STRONG\_SWEAR\_LANGUAGE WSC\_FOREIGN\_WORDS WSC\_ANGLICISM\_AND\_ALTERNATIVE
* Portuguese: WSC\_RACE\_AND\_ETHNICITY\_INSULTS WSC\_STRONG\_SWEAR\_LANGUAGE WSC\_FOREIGN\_WORDS WSC\_ANGLICISM\_AND\_ALTERNATIVE
* Ukrainian: WSC\_ANTYSURZHYK WSC\_STRONG\_SWEAR\_LANGUAGE WSC\_ANGLICISMS
* Italian: WSC\_BLASPHEMY WSC\_STRONG\_SWEAR\_LANGUAGE WSC\_RACE\_AND\_ETHNICITY\_INSULTS
* Dutch: WSC\_BLASPHEMY WSC\_STRONG\_SWEAR\_LANGUAGE WSC\_RACE\_AND\_ETHNICITY\_INSULTS
For custom rules that can be created by the on-premises clients, the category IDs are the file names UPPERCASED with no extension.
Whereas a **rule ID** is a unique identifier generated by the server automatically at the time the file is read. It can be learned from the Web API response as ‘**rule**’ or via browser’s development tools, specifically, inspect element under the ‘[**data-grammar-rule**](https://docs.webspellchecker.com/display/WebSpellCheckerCloud/How+to+disable+a+certain+grammar+rule+or+rule+category+for+all+users)**’**. It will have the following format: PREFIX +underscore(\_) + up to 20-digit number based on the rule’s pattern. Here is the example of rule ID from the JSON response: "WSC\_2664667314028094467".
Also, in the ‘**disabledRules.json**’ file you can find a list of style rules that disabled by default following the feedback of our customers.
### **1.3. Disabling specific rules or rules categories for cloud and standalone version v.5.29.0.0 (client-side)**
Also you can disable specific rules or rules categories using the **disabledRules** option on client-side by passing it into your HTML:
```
disabledRules: [‘RULEID’, ‘CATEGORYID”],
```
For example, if you want to disable all rules that are added by default, you have to specify the following:
```
disabledRules: ['WSC_GENDERED_AND_ABLEIST_LANGUAGE','WSC_RACE_AND_ETHNICITY_INSULTS','WSC_STRONG_SWEAR_LANGUAGE']
```
### **1.4. Using Web API to manage style guide feature for cloud and standalone version v.5.29.0.0**
Starting WebSpellChecker version 5.29.0.0, we introduce a range of powerful enhancements to our Web API. These enhancements apply to both the Cloud and Standalone versions, allowing you to effectively manage style guide functionality, including the ability to disable specific rules and their categories. Here are the three new API parameters at your disposal:
* **disable\_style\_guide=true**. This parameter allows you to completely disable the style guide feature.
* **disabled\_rules=RULE\_ID\_1,RULE\_ID\_1.** With this parameter, you can selectively disable individual rules by providing a comma-separated list of rule IDs. This applies to both style and grammar checks, empowering you to fine-tune the spell checking behavior as per your requirements.
* **disabled\_categories=CATEGORY\_ID\_1,CATEGORY\_ID\_1**. Similarly, this parameter enables you to disable specific rule categories by specifying a comma-separated list of category IDs.
Please refer to our comprehensive manual for a detailed guide on [how to leverage Web API and these parameters effectively](https://docs.webspellchecker.com/pages/viewpage.action?pageId=464879804).
## **2. Creating custom rules for on-premises clients v.5.29.0.0+**
WebSpellChecker’s Style Guide functionality allows on-premises clients to create a set of rules to mark a specific piece of text as a style error and optionally provide a list of replacements along with a descriptive message.
### **2.1. Limits and requirements**
#### Limitations
Style guide rules have the following restrictions:
* **Rules per file**: Maximum **2,000** rules per CSV file
* **File size**: Maximum **5 MB** per file
* **File format**: Must be `.csv` format
* **Files per directory**: Maximum **50** files per language directory
* **Forbidden characters**: The following characters are not allowed: `[]` `<>` `{}` `\\n` `\\t` `\\b` `\\r` `\\a` `\\f` `\\v`
* **Semicolon usage**: Semicolon (`;`) is reserved as a separator for multiple patterns/suggestions and cannot be escaped
* **Comma restrictions**: Commas are forbidden in patterns, suggestions and context columns. In descriptions, commas are allowed but the entire description must be enclosed in double quotes (`""`)
* **Pattern requirements**:
* Patterns cannot be empty in a rule
* Rules with identical patterns are not allowed
* **Column length limits**:
* **Patterns**: Maximum 150 characters per rule
* **Suggestions**: Maximum 150 characters per rule
* **Description**: Maximum 200 characters per rule
* **Context to include**: Maximum 150 characters per rule
* **Context to exclude**: Maximum 150 characters per rule
**Example with comma in** the description**:**
```
Patterns,Suggestions,Description,Context include,Context exclude
login,log in,"Use two words for the verb form, not the noun form.",,
setup,set up,"Use two words for the verb form, not the noun form.",,
```
### Best practices
1. **Use descriptive file names** that clearly indicate the purpose of the rules
2. **Organize rules by scope** (common vs. language-specific)
#### What will happen if you reach some of the mentioned limits?
The behavior for reaching the file size limit is as follows:
* If the file is already larger than the limit when AppServer is booting up, it is not read.
* If it overshot the limit at runtime, rules are not updated internally. Old ones are still used. The file is not reloaded until it’s of an appropriate size.
The behavior for reaching the file number limit is as follows:
* If there are more than 50 files at the start of the server for the language, none are loaded.
* If some number of new files are added during the work of the app, no new files are used, until the total number is 50 or fewer. Old (already loaded) files will continue to work as before. Moreover, their edits will also be readily applied.
### **2.2. How to create custom rules?**
To create a custom rule, on-premises clients have to follow the steps below:
1\. Navigate to the StyleGuide directory: **\\WebSpellChecker\AppServer\StyleGuide**
2\. Create the folder with the name **company**
3\. Navigate inside the **company** folder that is available by default starting v.5.29.1.0, and create another folder with the name that will relate to the **language alias** that you can find in the AppServerX.xml file. For example, **en** for English.
{% hint style="info" %}
If there are two aliases in the AppServerX.xml file, you can use any of them.
{% endhint %}
4\. Create a .csv file inside the created folders following the requirements described above. For example, the \`mycompany\_example.csv\` file inside:
**\\WebSpellChecker\AppServer\StyleGuide\company\en**
{% hint style="info" %}
The file name is meaningful. It consists of two parts:
* The first is the text before the first underscore (\_). It will be used as a “prefix” or “namespace” for all rules and categories you create. Conveniently, it can be the name of your company or organization, or a variation thereof.
* The second part is the rest of the text after the first underscore (which itself can contain other underscores). It stands for a category name for this rule set. Categories are logical groupings of your rules.
Custom rules categories can be multilingual. Thus, files
* StyleGuide/company/en/mycompany\_example.csv
* StyleGuide/company/de/mycompany\_example.csv
will add rules for the same category in two different languages (English and German, respectively). This is important to keep in mind, because when you disable a category, it applies to all the languages it’s defined for.
{% endhint %}
5\. Inside .csv we define rules in the following way:
* Input — Original text (TAB for several instances);
* Output — A substitute for the original text. Can be empty — no substitute;
* Message — Explanation (360 characters).
All the changes inside **StyleGuide/company** are live automatically.
mycompany\_example.csv
```
insurance man;
insurance agent,
Probably non-inclusive language. Choose an inclusive alternative.
```
How it will look like using WProofreader:
### Still have a question?
Please feel free to contact our [technical team](https://webspellchecker.com/contact-us/) if you are having any difficulties with the configuration.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.wproofreader.com/v6.12.0/features/old-style-guide-builder.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.