Finding the Atloria language support pages
Before you create a parsing job or start a documentation project, open the Supported Languages area in Atloria’s documentation workspace and find the exact technology pages you need. If you already reviewed parser coverage in Understanding Parser Coverage and Stack Compatibility, use that as background and focus here on locating the right support pages for your current project.
In Atloria, users typically rely on two page types:
- Programming language support pages
- Framework support pages
Start with the language you expect in the repository, then move to the related framework if the project uses one. For example, if your team is documenting an application built with a specific framework, first find the page for the underlying language and then open the page for the framework itself.
Use the documentation search and any available navigation filters to narrow the list. Look for the exact page title that matches the technology name instead of relying on memory or team shorthand. This matters when similar technologies appear close together in search results.
A reliable way to check that you are on the correct page is to confirm:
- The page title matches the language or framework you plan to analyze
- The page includes support status or parser availability details
- The page appears inside Atloria’s current documentation area, not from an old saved tab
If you opened a bookmark, shared note, or older internal reference, refresh your search from within Atloria and reopen the page from the current navigation. That helps you avoid planning work from an outdated support entry.
Checking whether a language is supported for parsing work
Once you open the language support page, look first for the support status shown on that page. This is the quickest way to confirm whether Atloria can use that language in code analysis and technical documentation workflows. Do not assume support based only on team experience or a previous project. Always verify the current language page before uploading code or planning automated documentation.
On the language page, review the parser details carefully. Focus on what the page says about:
- Parser availability
- Supported versions
- Recognized file extensions
- Known limitations
These details help you decide whether your repository is a good fit for parsing. A language may be supported in general, but your project can still run into issues if it uses a version outside the listed coverage or stores important code in file types that are not included on the page.
Compare the language page with the actual codebase your team plans to analyze. Check whether the main source files in the repository match the language listed in Atloria. If the project includes multiple languages, make sure the one you are reviewing is truly the primary language for the documentation work you want Atloria to perform.
This is especially useful when teams inherit older repositories or mixed-code projects. In those cases, the project name may suggest one language while the current implementation uses another. The language support page gives you a practical reference point before you move into parsing.
If the page shows limitations, note them early and share them with the team. That prevents confusion later when generated technical documentation covers only part of the codebase.
Confirming framework coverage before documenting an application
After you confirm that the base language is supported, open the related framework support page. In Atloria, framework coverage depends on the underlying language parser, so checking the framework page without confirming the language first can lead to the wrong expectations.
On the framework page, look for whether the framework is marked as:
- Supported
- Partially supported
- Not available
That label tells you how much framework-aware structure Atloria is likely to recognize when you parse the repository. A framework page can also include notes about the conventions Atloria understands. These notes are important because framework support is often tied to recognizable project patterns rather than just package names.
Review any framework-specific details about items such as:
- Routing patterns
- Component structure
- Configuration files
- Dependency layout
- Project organization conventions
These notes help you judge whether Atloria will identify the application in a framework-aware way or whether it will only read the code at the language level. That difference matters when you expect generated documentation to reflect application structure instead of just individual files.
For example, if the framework page shows only partial support, Atloria may still parse source files successfully but miss some framework-level relationships. In that case, your team may need to review generated output more closely and add manual explanation where needed.
Use the framework page as a planning tool, not just a yes-or-no check. If the framework is fully supported, you can move forward with stronger expectations for structured parsing. If support is partial, you can still proceed, but with a narrower scope and a more careful review plan.
Interpreting support details before starting a project
Support pages are most useful when you read beyond the headline status. Before your team starts a project in Atloria, make sure everyone understands the difference between full support, partial support, and unavailable. Those labels shape what Atloria can reasonably produce during parsing and documentation work.
Use the support details to interpret the likely outcome:
- Full support usually means Atloria is ready to parse the language or framework with broad expected coverage
- Partial support means some patterns are recognized, but important gaps may remain
- Unavailable means you should not plan parser-dependent work for that technology
Read the notes under the status carefully. They may mention limits such as:
- Unsupported language constructs
- Incomplete framework detection
- Version-specific gaps
- Reduced recognition for certain project layouts
These notes are where planning decisions become practical. If the page shows partial support or important limitations, you may still proceed, but you should adjust the repository scope or prepare for more manual documentation work. For example, your team might choose to parse only the supported part of a mixed project and document the rest by hand.
It also helps to record the confirmed status in project kickoff materials. Include the exact language and framework support result for the project so administrators, project managers, and writers all work from the same expectation. That avoids later disputes about why a parsing run did not produce framework-aware output.
When you need a shared reference during planning meetings, the support page itself should be the source of truth. Use the page title, status label, and notes directly rather than relying on verbal summaries.
Using support information to plan parsing and documentation scope
Once you confirm language and framework support in Atloria, use that information to define what will actually be included in the parsing and documentation effort. This is where support pages become part of project planning rather than just a pre-check.
Start by mapping confirmed support to the code areas your team wants to bring into Atloria. If your project includes several repositories, modules, or application areas, identify which ones use supported technologies and which ones do not. This helps you avoid assigning automated documentation work to code that Atloria cannot reliably interpret.
As you plan scope, flag any gaps early:
- Unsupported languages
- Partially supported frameworks
- Mixed-technology repositories
- Code areas that need manual review
This is especially important for teams working across multiple products or shared repositories. One part of the codebase may be a strong fit for parsing, while another part may require manual documentation from the start. Treat those as separate planning tracks instead of assuming one support result applies to the entire project.
Use the support pages to decide whether you should:
- Include the full repository in parsing
- Limit parsing to supported folders or technologies
- Split work across separate projects
- Assign manual writing for unsupported areas
These decisions also help with staffing. Writers, reviewers, and project leads need to know what Atloria can extract automatically and what still needs human explanation. If the support page shows only partial framework coverage, plan extra review time for structure, relationships, and terminology in the generated output.
A short support summary in the project brief can save time later. List the confirmed language page, the framework page, and any limitations that affect scope so everyone starts with the same assumptions.
Resolving common support-check mistakes
A few common mistakes can make a supported technology look broken when the real issue is a mismatch between the repository and the support page. When parsing results do not match expectations, return to the language and framework pages in Atloria and compare the details carefully.
If a language appears supported but parsing still fails, check whether the repository actually uses the version or file types listed on the language page. Support may apply only to certain versions or recognized file extensions. A team can easily assume support based on a language name while overlooking the exact coverage notes.
If a framework does not appear in results, verify two things:
- The base language is supported
- The framework page does not mark support as partial
A partially supported framework may allow parsing to run while still missing framework-aware relationships or structure in the output. In that situation, the result is not necessarily wrong—it may simply match the limits described on the page.
Disagreements often happen during project planning when one team member says a technology is supported and another says it is not ready. Resolve that by using the exact status and notes on the current Atloria support page as the shared reference. Avoid relying on screenshots from older discussions or copied notes from previous projects.
If a required language or framework is not listed at all, stop any parser-dependent planning for that part of the project. Instead:
- Record the technology gap in the project notes
- Plan manual documentation coverage for that area
- Share the gap with the team for product feedback or roadmap discussion
Overview
Atloria’s language and framework support pages help you answer three practical questions before parsing code: Is the language supported? Is the framework recognized? What level of output should the team expect? This document focuses on using those pages as planning tools inside real documentation workflows.
The most important ideas to carry forward are:
- Start with the language support page
- Check the related framework support page second
- Read the status label and the notes, not just the title
- Use support details to define project scope and review effort
These pages are especially useful when your team is preparing a new project, validating repository readiness, or deciding how much of the documentation can be generated automatically. They also help align writers, project leads, and administrators around a shared expectation before work begins.
In Atloria, support information is not just reference material. It directly affects how you plan:
- Parsing jobs
- Documentation coverage
- Review effort
- Manual writing for unsupported areas
If you need broader background on how parser coverage relates to technology fit, return to Understanding Parser Coverage and Stack Compatibility. For the next step, continue with Evaluating Language Support Before Parsing Code, which builds on these support-page checks and helps you decide whether a specific repository is ready for parsing.
Prerequisites
Before using this workflow in Atloria, make sure you have a few basics in place so the support pages are meaningful for your project planning. You do not need to start a parsing job yet, but you should know what technology you are trying to verify.
Have the following ready:
- Access to your Atloria workspace and documentation area
- The name of the programming language used in the repository
- The name of the framework, if the project uses one
- A basic understanding of which repository, module, or code area the team wants to document
It also helps if you already know whether the repository contains one technology or a mix of several. That makes it easier to compare the support pages against the actual project structure.
Before reading this document, you should already be familiar with parser coverage concepts from Understanding Parser Coverage and Stack Compatibility. That earlier guide explains the broader meaning of coverage and compatibility. Here, the focus is narrower: finding the correct support pages and using their status details to make planning decisions.
You are ready to use this guide if you can answer these basic questions:
- Which language is the main implementation language?
- Which framework, if any, sits on top of that language?
- Which codebase does the team want to parse in Atloria?
With that information in hand, you can use Atloria’s support pages to verify parser availability, confirm framework coverage, and set realistic expectations before moving on to Evaluating Language Support Before Parsing Code.
Was this page helpful?