Apply lang attribute to localized name:* values

[Arpan200502]

Description

Adds a lang attribute to localized tag values (e.g. name:fr, name:ja, alt_name:de) in the element Tags table.

The language code is extracted from the tag key and applied to the <td> element. This allows browsers to select appropriate fonts and improves accessibility for screen readers.

How has this been tested?

Tested locally by viewing elements with localized tags such as:

• name:fr
• name:ja
• name:zh-Hans

Verified that the rendered <td> includes the correct lang attribute.

Closes #6834

[Arpan200502]

got it , i will try using helpers

[hlfan]

Could you add some tests that match the mentioned keys while excluding others?

[Arpan200502]

Could you add some tests that match the mentioned keys while excluding others?

ok

[1ec5]

This is good enough for most of the common keys, though it wouldn’t cover a few common ones like name:zh-Hant. We also have some variant name keys such as alt_name:fr that would benefit from the same treatment.

There are a few versions of a more comprehensive regular expression floating around (JavaScript and Java). The part of the regular expression after name: seems like something we might end up using for other purposes in the future, so maybe we could extract it into a constant or function somewhere.

[hlfan]

Since we only need to find the substrings most likely to be BCP-47 strings, not validate them, we can go for something a little bit simpler.

I've been trying out some variants; this is my current pick:
/.+:([a-zA-Z]{2,3}(?:(?:[^a-zA-Z:_'"]\w+)+|\b|$))/

[Arpan200502]

Ok I will update that

[Arpan200502]

Moved the language extraction logic out of the view into BrowseTagsHelper as suggested, and updated the view to call the helper instead of running the regex directly in the template.

Also switched to the broader regex discussed earlier to better detect language codes in tag keys. Existing tests rendering the partial continue to pass with the helper in place.

[tomhughes]

In addition to my inline suggestions can you fix the commit to not have a 180+ character first line?

To be honest I'd just go with something like:

Fix language detection for name:* tags in data browser

I'm not sure mentioning specific files in the commit comment is a good idea, and including tests for the change is something that's expected and doesn't really need to be mentioned explicitly but if you do want to add more detail then do it in a separate paragraph and keep the initial subject line short.

[Arpan200502]

In addition to my inline suggestions can you fix the commit to not have a 180+ character first line?

To be honest I'd just go with something like:

Fix language detection for name:* tags in data browser

I'm not sure mentioning specific files in the commit comment is a good idea, and including tests for the change is something that's expected and doesn't really need to be mentioned explicitly but if you do want to add more detail then do it in a separate paragraph and keep the initial subject line short.

Thanks for the suggestions.

• Updated the commit message to keep the first line within the 80-character limit.
• Inlined tag_language(tag[0]) in the content_tag call and removed the temporary lang variable, since it was only used once.
• Fixed the indentation accordingly.

[pablobm]

Changes in this file are unrelated to the PR. Please remove them.

[hlfan]

Why not remove this partial entirely? Then some classes (py-1 border-secondary-subtle) can be reused.