You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In an element page’s “Tags” section, the table cell for the value of each localized name, such as name:fr=* or alt_name:en=*, should have a lang attribute set to the language code. This would help the browser choose an appropriate font. Screen readers would also be less likely to trip over text in languages that are related to the user’s preferred language.
For example, the Yellow Sea node has name:ja, name:ko, name:zh, name:zh-Hans, and name:zh-Hant all set to the same value, but the characters should look significantly different based on a language-appropriate font being applied. As I understand it, the visual differences are about as significant as presenting “Londres” as the English name for London. We probably don’t want to get into the business of choosing specific fonts, but even just telling the browser which language it’s in will help the browser choose the right font.
I don’t know of a comprehensive list of localizable keys. In principle, any freeform text key can have localized subkeys, but the most common one by far is name:*=*. Other common keys include addr:street/city/place:*=*, brand:*=*, operator=*, and species=*. Ideally, the code would check each subkey to see if it’s a valid IETF language tag, but I don’t think Rails comes with anything like that. As a workaround, a regular expression like the one mentioned in pnorman/spirit#80 (comment) would detect these language subkeys reasonably well.
From what I understand, localized tag values such as name:fr, name:ja, etc. are currently rendered without a lang attribute, which can affect font selection and screen reader behavior.
My plan is to:
Identify where localized tags are rendered in the element page view
Detect subkeys matching language patterns (e.g. name:<lang>)
Extract the language code and apply it as a lang attribute in the rendered HTML
Add tests to ensure correct rendering
I will also look into whether basic IETF language tag validation should be included or if a regex-based approach is sufficient.
Please let me know if this approach sounds reasonable.
There's no point asking questions if you're going to open a PR twenty minutes later without waiting for a reply - you might as well just go ahead and open the PR and if people have questions it can be discussed there.
Activity
Arpan200502 commentedon Mar 3, 2026
Hi, I’d like to work on this issue.
From what I understand, localized tag values such as
name:fr,name:ja, etc. are currently rendered without alangattribute, which can affect font selection and screen reader behavior.My plan is to:
name:<lang>)langattribute in the rendered HTMLI will also look into whether basic IETF language tag validation should be included or if a regex-based approach is sufficient.
Please let me know if this approach sounds reasonable.
Apply lang attribute to localized name:* values (openstreetmap#6834)
tomhughes commentedon Mar 3, 2026
There's no point asking questions if you're going to open a PR twenty minutes later without waiting for a reply - you might as well just go ahead and open the PR and if people have questions it can be discussed there.
Arpan200502 commentedon Mar 3, 2026
Thanks for the clarification — that makes sense. I’ll open a PR directly next time.
Apply lang attribute to localized name:* values (openstreetmap#6834)
Apply lang attribute to localized name:* values (openstreetmap#6834)
Apply lang attribute to localized name:* values (openstreetmap#6834)
Apply lang attribute to localized name:* values (openstreetmap#6834)
Apply lang attribute to localized name:* values (openstreetmap#6834)
Apply lang attribute to localized name:* values (openstreetmap#6834)