Which HTML Attributes Should Be Translated?
One of the most common HTML localization mistakes is translating the wrong attributes.
Some attributes contain user-facing text and should be reviewed during translation. Others are purely technical and should stay unchanged. Getting this wrong breaks CSS, scripts, analytics, and navigation — even when the visible copy looks perfect.
The one-question rule
Ask: Will a user meaningfully read this value?
- If yes → it may need translation.
- If no → leave it alone unless you have a deliberate localization plan.
Attributes that often should be translated
These may need translation when they are meaningful to users:
| Attribute | When to translate | Notes |
|---|---|---|
alt | Image is informative | Keep concise; empty alt="" for decorative images |
title | Tooltip / extra hint users may see | Avoid stuffing SEO keywords |
placeholder | Form hint text | Do not put required instructions only in placeholder |
aria-label | When it is the accessible name | Must stay accurate for screen readers |
value on buttons | Rare; prefer element text | <button>Text</button> is usually better than value |
Example: alt and title
<!-- Before -->
<img src="/hero.png" alt="Team reviewing a translated HTML page" title="Localization review">
<!-- After (Spanish) — src unchanged -->
<img src="/hero.png" alt="Equipo revisando una página HTML traducida" title="Revisión de localización">
Attributes that usually should not be translated
These usually control structure, styling, behavior, or routing:
| Attribute | Why leave it |
|---|---|
class | CSS and JS selectors |
id | Anchors, scripts, forms |
data-* | App state, analytics, config |
href / src paths | Routing and assets (unless you localize URLs on purpose) |
name on inputs | Form field keys |
type, role, rel | Machine semantics |
| Tracking IDs | Campaign and pixel integrity |
Example: dangerous change
<!-- BAD -->
<a class="кнопка-главная" id="купить" href="/купить" data-событие="клик">Buy</a>
Even if “Buy” is translated correctly, the attributes above will break styling and tracking.
<!-- GOOD -->
<a class="btn-primary" id="buy" href="/pricing" data-event="cta-click">Comprar</a>
What about href?
Translate the visible anchor text first. Only change the href value if your site intentionally uses localized URLs and you have redirects or a routing plan for them.
<!-- Usually correct -->
<a href="/pricing">Precios</a>
<!-- Only if /precios is a real route you maintain -->
<a href="/precios">Precios</a>
What about data-*?
Most data-* values are for scripts. Translating them can silently break features.
Exceptions are rare — for example, a data-label that is displayed in the UI. Prefer putting display strings in real text nodes instead of inventing display attributes.
translate="no" and attributes
The HTML translate="no" attribute protects element content. It does not replace careful attribute policy. Still review alt / title / aria-label on protected brands when those attributes should stay in the source language.
<span translate="no" title="HTML Translate">HTML Translate</span>
Checklist before you publish
- Diff the source and translated HTML — scan for changed
class,id,href,data-*. - Search the translated file for unexpected non-ASCII inside attribute names or technical values.
- Click every primary CTA and form in a browser.
- Validate that CSS still applies (no missing styles on buttons/nav).
How HTML Translate handles this
HTML Translate is built to translate visible text in static HTML files while aiming to leave technical attributes alone. Always run a quick browser pass afterward — especially for long languages and RTL.
Related guides:
- How to translate HTML without breaking layout
- Translate HTML code without breaking tags
- HTML translation best practices
FAQ
Should I translate aria-label?
Yes when it is the accessible name users hear. Keep it short and accurate; do not leave it in the wrong language while visible text is translated.
Should I translate content in meta tags?
Yes for description (and localized titles). Do not invent translations for technical meta that machines consume unless you know the format.
What if my CMS stores copy in attributes?
Prefer migrating user-facing strings into text nodes or a proper i18n resource file. Attribute-stored copy is harder to review and easier to break.
Final takeaway: translate attributes users read; leave attributes machines use. Attribute discipline is one of the highest-leverage habits in safe HTML localization.