## Opening the language and framework support catalog
To start evaluating support in Atloria, open the area where your team reviews code parsing readiness and supported technologies. If you already worked through [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage), return to the same supported languages or parser coverage view and use it as your starting point. This is the screen where Atloria lists the languages and frameworks it can recognize for documentation and code analysis work.

[SCREENSHOT: supported languages or parser coverage catalog showing language and framework entries]

When you open the catalog, focus on the information shown in each row. Atloria’s support view is most useful when you read it as a comparison list rather than a simple directory. Look for details such as:

| What to check | Why it matters |
|---|---|
| **Language name** | Confirms whether the base programming language is listed |
| **Framework name** | Shows whether Atloria recognizes a framework separately from the language itself |
| **Support status** | Helps you judge readiness for real project use |
| **Parser availability** | Indicates whether Atloria can analyze that technology |
| **Notes or limitations** | Explains important restrictions before you upload code |

Use any search box, filter choices, or category controls on the page to narrow the list to the technologies your repositories actually use. For example, if your team works with only a few languages, filtering the catalog makes it easier to compare support without scanning the full list.

Pay close attention to whether an entry is listed as a language only or as a language plus a specific framework. That difference matters. A language entry usually tells you Atloria can work with general source files in that language. A separate framework entry suggests Atloria may also understand framework-specific patterns, conventions, or file organization. If you only see the language and not the framework, treat that as base-level support rather than full framework-aware coverage.

## Reading support status and parser coverage details
Once you have the right entries on screen, the next step is to interpret the labels Atloria shows for each one. The support status tells you how confidently you can rely on that language or framework in a real documentation workflow. A label such as **fully supported** usually indicates the strongest level of readiness. **Partially supported** suggests Atloria can analyze some parts of the codebase but may miss framework-specific details or certain file patterns. **Preview** usually means the feature is available for testing but should be validated carefully before broad rollout. **Unsupported** means you should not expect dependable parsing results for that technology.

Parser coverage is the other key detail. In Atloria, parser coverage tells you how much of a repository Atloria can understand for documentation and analysis purposes. Depending on the entry, this may include source code structure, inline comments, configuration files, or framework-specific conventions. Coverage is not just about whether Atloria can open files. It is about whether Atloria can read them in a meaningful way and turn them into useful documentation inputs.

As you review each entry, look for indicators that describe the scope of coverage, such as:

- Supported file types
- Recognized syntax patterns
- Framework conventions
- Repository artifacts included in analysis
- Notes about unsupported cases

[SCREENSHOT: support entry with status label, parser coverage details, and limitation notes]

The limitation notes are especially important. If Atloria shows that a language is supported but also notes incomplete framework handling, limited syntax recognition, or missing support for certain repository artifacts, treat that as a planning signal. You may still get useful indexing or partial documentation extraction, but the results may not be complete enough for deeper technical documentation. Read those notes carefully before deciding that a language is ready for production use in your team.

## Checking whether your repositories match supported technologies
After reviewing the catalog, compare it directly against the repositories your team wants to bring into Atloria. Start with the languages used across those repositories and verify that each one appears in the supported technologies list. If a language is missing entirely, that repository should be treated as out of scope until support is added.

Next, check the frameworks your teams rely on. Some frameworks appear as separate entries in the support catalog, while others may not be listed on their own. If your framework is listed separately, review its support status and parser coverage independently. If it is not listed, do not assume framework-level support just because the base language appears. In that case, Atloria may still recognize the source files, but it may not understand framework-specific structure well enough for richer documentation output.

It also helps to compare the repository’s actual file patterns with what the catalog describes. Review whether the supported entry mentions the file extensions, project structure, or configuration formats your codebase uses. This is especially useful when your repositories depend on convention-heavy layouts or configuration-driven behavior.

Use a simple review checklist while comparing your repositories:

1. List the main language used in each repository.
2. Check whether that language appears in Atloria’s support catalog.
3. Look for any separate framework entry tied to that repository.
4. Review the parser coverage details for matching file types and project patterns.
5. Note any gaps, such as missing framework entries, unlisted file types, or unclear version coverage.

If you find a mismatch, write it down before rollout planning. Common gaps include a framework variant that is not listed, a newer language version than the one shown in the catalog, or repository files that fall outside the supported parser scope. Capturing those gaps early makes later testing much more focused.

## Assessing support for documentation extraction and code analysis
A supported language is only useful if the available parser coverage matches your documentation goals. In Atloria, this means looking beyond the support label and asking what kind of output you actually need. If your team wants repository indexing only, partial support may be enough. If you need detailed technical documentation generated from source code, you should expect much stronger parser coverage.

Start by matching Atloria’s coverage to the kind of information your team expects to extract. For example, you may need Atloria to identify code structure, pick up inline comments, recognize routes or components, or follow configuration-driven behavior. If the support catalog shows only limited structural parsing, Atloria may still help organize repository content, but the generated documentation may not reflect the deeper relationships your team expects.

This is where partial support needs careful interpretation. Partial parser support can still be valuable when you want Atloria to:

- Index repositories for browsing
- Recognize basic source files
- Support limited technical reference generation
- Provide a starting point for manual documentation work

However, partial support may fall short when you need:

- Complete source-to-document traceability
- Strong framework-aware documentation output
- Consistent extraction across all repository areas
- Reliable analysis of convention-based project structure

Different roles will judge fit differently:

- **Project Administrators** usually focus on whether Atloria can cover enough repositories to support rollout.
- **Documentation Managers** usually care whether the extracted content is complete enough to reduce manual writing effort.
- **Technical Writers** usually look for traceability between source material and the documentation they publish.

[SCREENSHOT: parser coverage details being reviewed against repository documentation goals]

When you evaluate fit, think in terms of outcomes, not just availability. A parser marked as available may still be too limited for your team’s documentation standards. The best choice is the one that supports the level of detail your workflow depends on.

## Comparing multiple languages and frameworks for rollout planning
If your organization works across several repositories, compare all relevant languages and frameworks side by side before deciding how broadly to use Atloria. This is especially important when one team uses a well-supported stack and another relies on a framework with only partial or preview coverage. A side-by-side review helps you avoid treating all repositories as equally ready.

Start by creating a shortlist of the languages and frameworks your teams actively use. Then review each one in Atloria’s support catalog and group them by support level. The goal is to identify which technologies are ready for immediate use and which ones should stay in a smaller evaluation phase.

A practical way to sort your rollout plan is:

1. Put **fully supported** languages and frameworks at the top of your list for initial rollout.
2. Place **partially supported** entries into a limited evaluation group.
3. Treat **preview** entries as test candidates rather than standard team choices.
4. Exclude **unsupported** technologies from your first rollout plan.

This comparison is most useful when you tie it to business decisions. If a repository needs both code analysis and documentation generation, prioritize technologies with strong parser coverage. If a repository only needs lighter indexing or reference support, a partially supported language may still be acceptable for a pilot.

You can also use the comparison to decide scope:

- **Organization-wide rollout** makes sense when most team stacks are fully supported.
- **Selected repository rollout** is safer when support is strong for only part of your technology mix.
- **Evaluation-only rollout** is the better choice when many key stacks are marked partial or preview.

[SCREENSHOT: side-by-side review of multiple supported languages and frameworks]

This review gives you a realistic adoption picture. Instead of asking whether Atloria supports code parsing in general, you are deciding whether Atloria supports *your* mix of languages and frameworks well enough for production documentation work.

## Resolving common gaps in support evaluation
Support reviews often become unclear when the catalog looks promising but your repository details do not line up perfectly. In Atloria, the best way to resolve that uncertainty is to go back to the support entry and read it more narrowly.

If a language appears supported but your framework is missing, first check whether Atloria lists frameworks separately from base-language parsing. A listed language does not automatically mean Atloria understands the framework conventions built on top of it. In that situation, treat the repository as language-supported but framework-unconfirmed until you verify otherwise.

If parser coverage looks available but important repository files are not mentioned, review the coverage details for supported file types, syntax scope, and limitation notes. Atloria may support core source files while excluding configuration files, generated artifacts, or framework-specific folders that matter to your documentation process.

Another common issue is version mismatch. If your team uses a newer language or framework version than the one shown in the catalog, do not assume the same support applies. Record that difference as a rollout risk and keep the repository in evaluation status until you confirm the match.

When support status is unclear for documentation work, separate code recognition from documentation extraction. Atloria may be able to read code structure without extracting the documentation artifacts your team expects. That distinction matters when your goal is not just analysis, but publishable technical documentation.

Use these checks to resolve uncertainty:

- Confirm whether the framework has its own entry
- Compare your repository file types to the coverage notes
- Check whether the listed support appears to match your version
- Review whether the entry describes documentation extraction, not just code parsing

If questions remain after reviewing the catalog, keep the repository in a limited test group rather than including it in a broad rollout. That gives your team a safer way to validate real results before making Atloria part of standard documentation operations.

## Overview
- This document helps you judge whether Atloria’s supported languages and frameworks align with the repositories your team wants to analyze.
- You will use the supported languages or parser coverage catalog to review:
  - **Language entries**
  - **Framework entries**
  - **Support status**
  - **Parser coverage**
  - **Limitation notes**
- The goal is not just to confirm that a language appears in Atloria, but to decide whether the available coverage is strong enough for your documentation workflow.
- This evaluation is most useful when you are planning:
  - Project onboarding
  - Code parsing workspace use
  - Documentation generation
  - Multi-team rollout decisions
- If you need help locating the catalog itself, refer back to [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage).

Use this guide when you need to answer practical questions such as:

- Can Atloria work with the languages in our repositories?
- Does Atloria recognize our framework separately from the base language?
- Is parser coverage deep enough for technical documentation, not just indexing?
- Which repositories are ready for rollout now, and which should stay in evaluation?

This guide focuses on reading and comparing what Atloria shows in its support listings. It does not repeat the earlier walkthrough for finding that screen, and it does not go deep into parser compatibility rules. The next document, [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility), covers that in more detail.

## Prerequisites
- You should already know how to open the supported languages or parser coverage area in Atloria. If not, use [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) first.
- Have a basic list of the repositories, languages, and frameworks your team wants to evaluate.
- Be ready to compare Atloria’s catalog against real repository characteristics, including:
  - Main programming language
  - Framework or stack choice
  - Common file types
  - Project structure patterns
  - Any known version differences
- This guide is most useful for users involved in project setup, documentation planning, or rollout decisions, especially:
  - Project Administrators
  - Documentation Managers
  - Technical Writers

Before you begin, it helps to gather a short internal checklist for each repository you plan to review:

- Repository name
- Primary language
- Framework used, if any
- Important file formats
- Whether you need indexing only or deeper documentation extraction

You do not need advanced technical knowledge to use this guide, but you do need enough familiarity with your team’s repositories to recognize the language and framework names Atloria shows in the support catalog. If your team is evaluating Atloria for broader adoption, keep notes as you review each support entry so you can compare repositories consistently.

For the next step in this learning path, continue with [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility).