## Opening the Supported Languages Page
To evaluate coverage in Atloria, start from the signed-in workspace and open the area where Atloria lists supported languages and frameworks. If you have already worked through [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage) or [Evaluating Supported Languages and Parser Availability](doc:evaluating-supported-languages-and-parser-availability), use the same support listing rather than checking project screens first.

1. Sign in to Atloria and enter your main workspace.
2. Open the documentation or code parsing area where Atloria shows supported languages.
3. Look for the page that presents a language support matrix or a structured list of languages and frameworks.
4. Confirm that the page shows each language as its own entry, with support details displayed beside it.
5. Review the headings at the top of the list before you begin comparing your stack.

On this page, you are looking for three things:

- A language name in each row or entry
- A parser support indicator for that language
- A framework coverage area that shows related frameworks or stack options

The parser support indicator is the first checkpoint. It tells you whether Atloria can read and analyze source files for that language. The framework coverage area gives extra detail about common frameworks associated with that language. That second part matters when your team depends on a specific frontend or backend stack.

[SCREENSHOT: Supported Languages page showing a table or list with language names, parser support status, and framework coverage details]

Before making any decision, make sure you are reading the current support matrix on the page itself. Do not rely on memory from an earlier review, especially if your team is planning a new project import or code upload. If the page layout includes status labels, badges, or grouped sections, use those visible markers as your source of truth for the latest coverage shown in Atloria.

## Checking Whether a Language Has Parser Support
Once you are on the Supported Languages page, read each language entry from left to right and focus first on parser support. This tells you whether Atloria can process files written in that language before you worry about framework details.

1. Find the language your project uses in the list.
2. Check the parser support label or status shown for that language.
3. Note whether the status appears as available, limited, or unavailable.
4. Read any nearby qualifier, badge, or note that changes how you should interpret that status.
5. Repeat this for every language used in your repository.

A language marked as available means Atloria shows parser support for that language. A language marked as limited means Atloria may process only part of what your team expects, so you should treat results more carefully. If a language is shown as unavailable, Atloria is signaling that code in that language is not currently covered by the parser listing on this page.

It is important to separate language support from framework coverage. A language can appear in the list with parser support, while a framework connected to that language may still have different coverage. When you read the page, do not assume that a supported language automatically means every framework built on top of it is equally covered.

Use the visible status markers exactly as they appear on the page. If Atloria shows a support note, a qualifier, or a limited-status label, include that in your evaluation. Those details affect how complete the parsing results may be when you later upload code in the parsing workspace.

If you need a refresher on how parser labels work, return to [Understanding Supported Languages Frameworks and Parser Availability](doc:understanding-supported-languages-frameworks-and-parser-availability) or [Understanding Parser Coverage and Stack Compatibility](doc:understanding-parser-coverage-and-stack-compatibility). Here, the goal is narrower: confirm whether each language in your stack has a parser status you can rely on for planning.

## Reviewing Framework Coverage for Your Stack
After checking parser support for each language, move to the framework coverage area in the same row or entry. This is where Atloria helps you judge whether your actual stack matches the technologies shown on the support page.

1. Locate the language entry for your project.
2. Look under or beside that language for the listed frameworks.
3. Search the framework list for the exact framework your team uses.
4. Check whether Atloria marks that framework as fully covered, partially covered, or simply listed without a stronger status.
5. Compare every major framework in your stack, not just the primary one.

Many projects use more than one framework. For example, your team may have one framework for the frontend and another for the backend. Review both against the page instead of stopping after the first match. If Atloria shows multiple frameworks under one language, compare them one by one and note any differences in coverage markers.

When reading framework coverage, stay literal. If your framework appears in the list, that is a stronger signal than assuming a similar framework is covered. If your framework is not shown, do not treat a neighboring or related framework as a substitute unless Atloria clearly presents it that way on the page.

[SCREENSHOT: A language entry expanded or visible with several framework names and coverage indicators]

This step is especially useful when your repository uses a common language but depends on a specific development stack. A language may be supported broadly, while framework coverage gives you a more realistic view of how well Atloria can support documentation work for that stack. If your project combines several layers, such as web interface, server logic, and supporting tools, compare each visible framework entry separately so you can spot gaps before rollout.

## Comparing the Page Against a Real Project Technology Stack
The most reliable way to use the Supported Languages page is to compare it against a written list of the technologies your project actually uses. This keeps you from making decisions based on only the most visible part of the repository.

1. Write down every main language used in the project repository.
2. Add the major frameworks used for the frontend, backend, and any other important layer.
3. Open the Supported Languages page in Atloria.
4. Match each language on your list to a language entry on the page.
5. Check the framework coverage shown for each matching language.
6. Mark any item that is missing, limited, or unclear.
7. Decide whether the stack looks fully supported, partially supported, or in need of follow-up.

A simple comparison table can help your team stay aligned:

| Project technology | Found on Supported Languages page | Visible support result |
|---|---|---|
| Primary frontend language | Yes or No | Available, limited, or unclear |
| Primary frontend framework | Yes or No | Listed, partial, or not shown |
| Primary backend language | Yes or No | Available, limited, or unclear |
| Primary backend framework | Yes or No | Listed, partial, or not shown |

As you compare, focus on the technologies that shape documentation output most directly. If a language is central to the repository, its parser status matters more than a minor supporting script. If a framework drives routing, component structure, or application behavior, its coverage matters more than a small helper library.

When you finish, classify the stack in plain terms:

- **Fully supported**: all major languages and frameworks appear with strong coverage signals
- **Partially supported**: some major items are limited or missing
- **Needs follow-up**: one or more core technologies are unclear, unlisted, or mixed across support levels

This comparison gives Project Administrators, Documentation Managers, and Technical Writers a shared basis for deciding whether to move ahead with code parsing and documentation generation.

## Interpreting Gaps, Partial Coverage, and Mixed-Stack Results
Not every project will line up neatly with the Supported Languages page. In Atloria, gaps and mixed results do not always mean you must stop, but they do mean you should plan more carefully.

If a language is supported but your framework is not listed, treat that as a partial confidence result. Atloria may still be able to analyze source files in that language, but the framework-specific structure your team relies on may not be reflected clearly in the support matrix. That can affect how complete or organized the resulting technical documentation feels.

If your repository combines supported and unsupported languages, review the stack by importance rather than by file count alone. A project may still be workable if the main documentation-driving language is supported and a smaller secondary language is not. On the other hand, if a major part of the product depends on a language or framework with limited coverage, expect uneven results.

Partial parser support usually means Atloria can recognize some parts of the codebase but may not capture everything with the same depth or consistency as a fully supported stack. In practical terms, this can lead to documentation that is useful in some areas and thinner in others. That is why limited support should be treated as a planning signal, not just a label.

Different roles can use these results in different ways:

- **Project Administrators** can decide whether a rollout should proceed now or wait for clearer support.
- **Documentation Managers** can estimate how much manual review or cleanup may be needed after parsing.
- **Technical Writers** can identify where they may need to supplement generated content with hand-written pages.

When support is mixed, record what is strong, what is partial, and what is missing. That shared view helps teams avoid overpromising what the first documentation pass will deliver.

## Resolving Common Questions When Coverage Is Unclear
Some support decisions are straightforward, but others require a closer reading of the page. When coverage is unclear, use the visible language and framework indicators together instead of relying on only one part of the listing.

If a language appears on the page but your framework does not, treat the language as supported only at the language level. Atloria is showing that it can work with that language, but it is not confirming framework-specific coverage for your exact stack. In that case, mark the framework as unconfirmed in your planning notes.

If a framework is listed but the parser status for its underlying language is limited, the language status should guide your expectations. The framework listing is useful, but limited parser support means results may still be incomplete. Do not treat the framework name alone as proof of full readiness.

If your project uses a custom or in-house framework, look for the underlying language first. Then compare the custom framework to any similar framework names shown on the page without assuming they are equivalent. If Atloria does not list your framework directly, record it as not listed rather than forcing a match.

Mixed support levels across the stack are also common. For example, one part of the project may show strong language support while another shows limited framework coverage. In that situation, separate your evaluation into parts:

- Core language support
- Frontend framework coverage
- Backend framework coverage
- Any custom or unlisted layers

[SCREENSHOT: Example of a support review where one language shows available parser support and another entry shows limited or missing framework coverage]

This approach makes rollout readiness easier to judge. Instead of asking whether the whole project is simply supported or unsupported, ask which parts of the stack Atloria clearly covers and which parts may need extra review. That gives your team a more realistic basis for planning uploads, parsing, and documentation review.

## Overview
Use the Supported Languages page in Atloria as a decision screen before you upload or parse a repository. The page is most useful when you read it in two layers: first by language, then by framework. That order helps you confirm whether Atloria can analyze the source files at all before you decide how well it matches the structure of your specific stack.

Key points to keep in mind:

- Start with the language entry, not the framework list
- Check the parser status shown for each language
- Review framework coverage separately for every major part of the stack
- Treat limited or missing coverage as a planning signal
- Compare the page against your real repository, not against assumptions

This document builds on the earlier evaluation steps in [Evaluating Supported Languages and Parser Availability](doc:evaluating-supported-languages-and-parser-availability). That earlier guide explains how to read parser availability in more detail. Here, the focus is on combining parser status with framework coverage so you can make a practical support decision for a real project.

A good evaluation result is not just “yes” or “no.” In many cases, the better outcome is a clear support profile:

- Which languages are clearly supported
- Which frameworks are explicitly covered
- Which parts of the stack are only partially supported
- Which items need follow-up before rollout

That support profile is useful across project setup, code parsing, and documentation planning. It helps teams decide whether to proceed with confidence, prepare for manual review, or pause until they have clarified important gaps. The next document, [Using Language Support Information During Project Planning](doc:using-language-support-information-during-project-planning), shows how to turn this evaluation into rollout and documentation decisions.

## Prerequisites
Before evaluating framework coverage in Atloria, make sure you have the basic information needed to compare your project against the Supported Languages page. You do not need deep technical expertise, but you do need a clear list of the technologies your team is using.

Have these items ready:

- Access to your Atloria workspace
- Permission to view the Supported Languages page
- A list of the main languages used in the repository
- A list of the main frameworks used by the project
- Enough project context to tell which technologies are core and which are secondary

It also helps if you have already completed the earlier reading in this section, especially:

- [Viewing Supported Languages and Parser Coverage](doc:viewing-supported-languages-and-parser-coverage)
- [Evaluating Language and Framework Support in Atloria](doc:evaluating-language-and-framework-support-in-atloria)
- [Evaluating Supported Languages and Parser Availability](doc:evaluating-supported-languages-and-parser-availability)

Those guides explain how to find the support listing and how to read parser status labels. This document assumes you already know where the page is and how to identify the main support indicators.

Before you begin, avoid these common mistakes:

- Checking only one language in a multi-language repository
- Assuming a listed language means every framework under it is covered
- Treating a similar framework name as an exact match
- Ignoring limited-status labels because the language itself appears on the page

If your project includes a frontend, backend, and custom internal layer, gather all three before you review the page. The more complete your stack list is, the more accurate your support decision will be. Once you have that list ready, you can move directly from support evaluation into planning decisions in [Using Language Support Information During Project Planning](doc:using-language-support-information-during-project-planning).