docs: unify writing style and polish component intros (Badge, Card)

[ariansj01]

Goal: Improve clarity and consistency in the Card documentation through small, low-risk text edits.
Changes:

Standardize component names in the introduction (CardContent, CardHeader, CardMedia, CardActions, CardActionArea).

Ensure brand consistency: “Material UI” → “MUI”.

Fix minor grammar issues: e.g., “Often a card allow…” → “Often a card allows…”, add missing commas.

Add a short API link after the main header.

Add a brief accessibility note under Media, encouraging proper alt text when using component="img".
Scope: Text-only edits in docs/data/material/components/cards/cards.md; no structural or API changes.

[mui-bot]

Netlify deploy preview

• docs/data/material/components/badges/badges.md
• docs/data/material/components/cards/cards.md

Bundle size report

Bundle	Parsed size	Gzip size
@mui/material	0B(0.00%)	0B(0.00%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/system	0B(0.00%)	0B(0.00%)
@mui/utils	0B(0.00%)	0B(0.00%)

Details of bundle changes

Generated by 🚫 dangerJS against 4704224

[ariansj01]

Hey @zannager @brijeshb42 @oliviertassinari 👋
I’ve finished polishing the docs for the Card and Badge component.
Could you please review when you have a moment?
Let me know if there’s anything else to adjust 🙂

[mapache-salvaje]

Hi @ariansj01 ! I appreciate your interest in making improvements to the Material UI docs. However, many of the changes here are incorrect (for example, MUI and Material UI are not synonymous) or do not align with our style guide and best practices (for example, we avoid latinisms such as "e.g." when adding to or editing the docs). As such, I can't really offer a review and am going to close this.

To improve your chances of getting a docs PR reviewed, here's what I recommend:

• Familiarize yourself with our general style guide, our style conventions for components, and our best practices for writing great docs
• For good examples of component docs that adhere to our best practices and most up-to-date information architecture, check out Snackbar, Alert, and Divider
• Before opening a PR and making any changes, start by opening an issue to propose your changes and discuss them with the maintainers (like me, who you can always ping for comments)
• Limit the scope to one doc per PR

Another great way to get involved is to search for the docs tag on open issues and see if there's anything you're interested in working on - this way you know you'll be solving a concrete problem that's already been identified.

Hope this helps!

[ariansj01]

Thank you very much for the detailed feedback and clarification!
I completely understand I’ll review the style guide and component conventions more carefully next time.
For my next contribution, I’ll start by opening an issue to propose the doc improvements and keep the scope to one component per PR.
I really appreciate your time and guidance 🙏