# Locale-specific checks
One of the main features in lexiQA is something that doesn't require any input from the user at all. Any issues that have to do with locale-specific grammatical or other conventions are included by default in the range of our QA checks, thus taking away from the user the burden of in-depth configuration. In order to run QA checks without large numbers of false positives, you have to do absolutely nothing! We have developed a rigorous model for designing and building algorithms which can handle things like punctuation rules and numerical conventions in every locale we support.
Our locale-specific checks cover a very wide range of error classes. More detailed information on the error classes we support is available to lexiQA users only.
# Terminology - glossaries
We understand the importance of using approved terminology in your translation projects and also using it consistently. In order to accommodate different types of terminological data, in lexiQA you can perform checks with three kinds of glossaries:
- Bilingual termbases (items are marked in the Editor with a green underline and a suggestion is provided)
- Monolingual brandname lists (items are marked in the Editor with a red underline)
- Monolingual blacklisted word lists (items are marked in the Editor with a red strikethrough)
You can either upload a new glossary in a new or existing lexiQA project or select an existing one from your account's User settings. We currently support XLSX, XLS, CSV and tab-delimited TXT files. The first row of your terminology file(s) need(s) to have language/locale codes that match the language pair of your project file(s). The four-letter locale codes (in the form of xx-YY, where xx is lowercase and YY is uppercase) need to follow the conventions set out in ISO 639-1 (for the language) and in ISO 3166 (for the country), e.g. en-US, en-GB, pt-PT, pt-BR, etc.
When uploading a new glossary to your account, depending on the type of file you are adding to your resources, you can choose to apply bidirectional checks and/or case-sensitive checks to each particular file. Note that this is a property that cannot be reversed, so if you wish to change the file's configuration later, you'll need to reupload the file and select the required settings again.
Once a glossary file has been uploaded to your user account, it is saved there for future use. You can use the Name and Type header descriptions in the glossary table for sorting and the action buttons on the right-hand side column of the same table to download the file in question or to delete it.
# Custom checks & checklists
These custom checks can be added and saved to your User settings for future use.
You can create checklists by bundling custom checks together. You can use any of these checklists in one of your projects by selecting it in a new or existing lexiQA project.
Active custom checks can be filtered in or out in any file checked in lexiQA's Editor using the appropriate toggle filter. If there happens to be an overlap between a custom check and one of lexiQA's default checks, then the custom check will take priority as it's user-defined.
lexiQA uses continuously updated proprietary dictionaries for spellchecking. This feature is active by default when creating a new project, however you can deactivate it by using the toggle either before creating a new project or after having created one, in the Project settings page.
If spellchecking is active, and spelling issues found will be marked with a purple underline in the checked file in lexiQA's Editor. When available, the Editor's tooltip will also provide you with suggestions for correcting the spelling issue that has been detected.
For morphologically challenging locales, such as Burmese, Hindi, Gujarati, Marathi, Tamil, and Thai, lexiQA deploys specialist spellchecking mechanisms (which are enhanced with NLP features and go well beyond standard wordlists) which can dramatically reduce noise.
In order to augment these spellchecking capabilities and reduce the potentially numerous false positives of spelling issues found in a checked file, lexiQA has also developed the following Named Entity Recognition feature.
# Named Entity Recognition
It is not uncommon for technical and marketing content to feature numerous proper names, like names of organisations, people or brands, most of which would be unknown to a spellchecking dictionary. Normally such cases can be addressed with monolingual inclusion/exclusion lists, however these can require a lot of maintenance work to keep them up-to-date for any new content. lexiQA has developed a Named Entity Recognition (NER) module which can be deployed alongside our spellcheckers to identify and filter out all those names that could generate an inordinate number of false positives when spellchecking. This feature is normally deployed as a separate on-demand module, as it requires distinct infrastructure to run.
After a new project has been created, in the Project overview page you can access a stand-alone report containing all the inconsistent segments in your project. This applies regardless if the project is made up of only one file or multiple ones - in fact, if there are multiple files in your project, you'll be able to see inconsistencies across all project files in the same place. This report is also where you'll be able to fix all these inconsistencies more efficiently.
The Inconsistencies report contains a detailed break-down of all inconsistencies found amongst source and target segments in your project file(s). In the header of the report you will find two toggles: each toggle can be turned on or off, depending on the type of cross-file inconsistency you want to see (target or source). By default both types will be shown in the report and all results are grouped for convenience.
By default you see the inconsistent parts highlighted with red (removed parts) and/or green (added parts). The first segment of each inconsistency stands as the basis against which a comparison is performed and additions/removals are generated. In order to see an inconsistent segment without highlights, click See raw at the bottom of the segment. To switch back to the highlighted version, click See diff.
Hovering over the Segment info button will display basic information about a particular segment, specifically the file where this segment appears and the segment no. in said file.
In cases of target inconsistency, before making a decision about which translation you would like to apply across all inconsistent segments, it would be useful to be able to see the text surrounding the segments in question. Clicking on See context button will open the respective file in the Editor and take your view directly to that particular segment in order to review its context.
The Apply selection function allows you to overwrite all other inconsistent segments with the translation contained in the segment you have selected. If required, you can also make changes to the selected translation and again those changes will be applied across all other segments in that group to maintain consistency.
Inconsistent segments (same source with different target, and vice versa in the same project) are also marked in the Editor with an inconsistency label at the bottom right of each target segment. This label is there for information only and it allows you to jump to any matching inconsistent segment(s) within the same file.
# Length checks
When creating a new project, or after having created one (in the Project settings page), you can configure the length check feature which will check for expansion or character limits in the target text. Values can be defined in percentages or number of characters in the length check fields. In the rather rare case that you wish to check that the target text has exactly the same length as the source, then enter 0 in both fields. (If you don't wish this feature to be activated at all, just leave the relevant fields blank.)
Segments which have been found to have length issues are marked with a length indication label at the bottom right of each segment in the Editor. You can then use this information to make appropriate adjustments if necessary.
# QA Report
The QA report provides a read-only overview of all the issues that lexiQA has found in your project, using the parameters you have defined. The first section of the report contains a full listing of all file segments where an issue has been found. Each issue identified is either underlined or highlighted and colour-coded in a user-friendly way so that the issues are easier to track in the text. The colour coding matches the colours of the toggle filters in the header of the report. (For more information on how to use these toggles, go here.)
The second section of the QA report contains the project's statistics in separate tabs:
# File info
The File info tab contains essential file data for your reference, such as error ratios (including corrected and ignored error ratios).
The Errors tab contains a comprehensive breakdown of the errors found by lexiQA in all error classes and user-selected functions (such as terminology and length checks), including matching information for errors corrected and ignored by the user.
In the Statistics tab you will find consolidated bar graphs with all error data for your project file, including Corrected errors and Ignored errors. These graphs and all error statistics are automatically updated every time you apply corrections on the file in lexiQA's Editor.
In the Downloads tab you can also save and share the statistics of a QA report, using either of the following two methods:
- download an Excel file containing all project data and analytics, and save it for offline use, or
- make a copy of the unique URL link for this report and share it by email or another online application.