Subject: Add Language Breakdown Section to Mobile View

[MadaraMods]

Hello GitHub Mobile Team, 

It would be great to see a language usage breakdown in the mobile app, similar to what’s shown on the desktop version of GitHub repositories. 

For example, showing the programming languages used in a project along with their percentage distribution (like Kotlin 47%, C 22%, etc.) helps developers quickly understand the tech stack of a repository. 

This feature is especially useful for mobile users who explore open-source projects and want to assess language relevance without switching to desktop. 

Please consider adding this section to the mobile interface for better transparency and developer experience. 

Thanks again for your work! 

Best regards, 
MadaraMods

[krishparmar22242]

This is excellent suggestion for improving the utility of the GitHub Mobile app. Being able to see the Language Breakdown at a glance is one of the quickest ways for a developer to gauge if a project matches their expertise or if they have the right environment to contribute.
Here is a breakdown of why this feature is highly requested and how you can best advocate for it.

Understanding the Current Limitation
On the desktop version, the "Linguist" library (which GitHub uses to calculate these percentages) has plenty of sidebar space to display the full color-coded bar. On mobile, screen real estate is limited, so the app currently only displays the Primary Language (usually at the top near the repository name) rather than the full distribution.

The Value of Your Suggestion
Adding the full breakdown—including languages like Rust, C, or Shell—is critical for "polyglot" projects like the one in your screenshot (KernelSU-Next). For a mobile user, knowing that a project is nearly 50% Kotlin but also requires C and Rust knowledge completely changes how they assess the repository's complexity.

How to Drive This Feature Forward
GitHub’s mobile engineering team uses these community discussions to "heat map" which desktop features are missed most by mobile users. By providing a clear screenshot and explaining the "why" (assessing language relevance without switching to desktop), you have provided the exact type of user story that helps product managers prioritize a feature in the development sprint.

The "Linguist" Logic
It is also worth noting that the data for these percentages already exists in the GitHub API. This means implementing the feature wouldn't require new data processing—it is purely a UI/UX task to bring that existing data into the mobile view in a way that remains readable on small screens.

Final Thoughts
Consistent feedback like this is what transformed the mobile app from a simple notification viewer into the powerful tool it is today. Your focus on "Developer Experience" and "Transparency" is exactly what the community needs to see.

If this analysis of why the feature is missing and how it can be implemented helps you feel heard by the community, please consider marking this as the accepted answer so we can highlight this request to the GitHub Mobile Team!

[disjoke]

Başla

[MadaraMods]

This is excellent suggestion for improving the utility of the GitHub Mobile app. Being able to see the Language Breakdown at a glance is one of the quickest ways for a developer to gauge if a project matches their expertise or if they have the right environment to contribute.
Here is a breakdown of why this feature is highly requested and how you can best advocate for it.

Understanding the Current Limitation
On the desktop version, the "Linguist" library (which GitHub uses to calculate these percentages) has plenty of sidebar space to display the full color-coded bar. On mobile, screen real estate is limited, so the app currently only displays the Primary Language (usually at the top near the repository name) rather than the full distribution.

The Value of Your Suggestion
Adding the full breakdown—including languages like Rust, C, or Shell—is critical for "polyglot" projects like the one in your screenshot (KernelSU-Next). For a mobile user, knowing that a project is nearly 50% Kotlin but also requires C and Rust knowledge completely changes how they assess the repository's complexity.

How to Drive This Feature Forward
GitHub’s mobile engineering team uses these community discussions to "heat map" which desktop features are missed most by mobile users. By providing a clear screenshot and explaining the "why" (assessing language relevance without switching to desktop), you have provided the exact type of user story that helps product managers prioritize a feature in the development sprint.

The "Linguist" Logic
It is also worth noting that the data for these percentages already exists in the GitHub API. This means implementing the feature wouldn't require new data processing—it is purely a UI/UX task to bring that existing data into the mobile view in a way that remains readable on small screens.

Final Thoughts
Consistent feedback like this is what transformed the mobile app from a simple notification viewer into the powerful tool it is today. Your focus on "Developer Experience" and "Transparency" is exactly what the community needs to see.

If this analysis of why the feature is missing and how it can be implemented helps you feel heard by the community, please consider marking this as the accepted answer so we can highlight this request to the GitHub Mobile Team!

Thank You For Reply

[krishparmar22242]

If this explanation helps you find the application form and get past the pricing page please consider marking this as the accepted answer so it can help other students in the community!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐