Fix Nearby description showing raw HTML tags

[Salehcodes]

Description (required)

Fixes #6594

The description text shown in the Nearby map bottom sheet previously displayed raw HTML tags such as <br> and <b>, instead of rendering formatting. This reduced readability and made the UI appear visually broken.

This PR updates the description binding in ExploreMapFragment.passInfoToSheet() to use:

HtmlCompat.fromHtml(descriptionText, HtmlCompat.FROM_HTML_MODE_LEGACY)

This allows HTML to be rendered as styled text (e.g., bold and line breaks), matching the formatting already used in the Details screen.

Tests performed (required)

Tested on:

Build variant: betaDebug

Device: Samsung Galaxy S23

Android version: Android 16 (API level 35)

Steps:

Opened Explore → Map

Selected a nearby marker and tapped the bottom info banner

Verified that HTML is properly rendered:

<b> → bold text

<br> → correct line break

No visible raw HTML tags

Uploaded a test image to Beta Commons to ensure environment functionality

Test upload URL:
https://commons.wikimedia.beta.wmflabs.org/wiki/File%3ATest_html_tags.jpg

Screenshots (for UI changes only)

[RitikaPahwa4444]

Thanks @Salehcodes for your contribution. I'm not sure if users really pass HTML tags in these fields. There are some existing issues with more context around this. Could you please check those and see if this PR handles those use cases?

[Salehcodes]

Thanks a lot for your feedback :)
My assumption was based on the fact that the HTML tags are already being rendered correctly in the Details screen from the same bottom sheet. So I applied similar handling here to make the behavior consistent.
If there are cases where descriptions are not expected to contain HTML, I’d be happy to review and ensure we also cover those scenarios.
Since I’m still new to the project, could you please share the related issue numbers you mentioned so I can read through the context and confirm whether this PR fully addresses them?
Thanks again for guiding me.

[RitikaPahwa4444]

One that was fixed recently for the author field: #5030.

It's not a natural for a user to use tags, but since you're saying our codebase is inconsistent, I'll take a look at those areas and get back to you. Would you recommend having these checks for every edit text field within the codebase?

[Salehcodes]

Thank you, yes i think its very good idea as by checking we make sure nothing like this happens again in any field.

[whym]

In #5030 I worked with rendered HTML with no wiki code. I believe here we are working with wiki syntax, which happens to allow limited HTML, too. EDIT: no, it looks like it's also non-wiki HTML, judging by the fact that two bold text in https://commons.wikimedia.beta.wmcloud.org/wiki/File:Not_Googleplex.jpg both appeard as <b>.

Still, I think different text fields can have different expectations:

• text fields dealing with file page content - wiki code or HTML or plain text, depending on how you retrieve
• text fields dealing with Wikidata caption - plain text (with language specified)

[RitikaPahwa4444]

Thank you @whym for your inputs!

My only point here is that we need to understand if this is happening due to some glitch or we're just dealing with user input. If it's the latter, then we need not solve for it. Users can even decide to use asterisks for bold, underscores for italic, etc. which isn't HTML but a common behaviour on chat applications.

And if not, then your first point about file content retrieval would help.

@Salehcodes could you please confirm the use case once and possibly share a screen cast too for the inconsistencies you were referring to?

[github-actions]

✅ Generated APK variants!

• 🤖 Download betaDebugAPK
• 🤖 Download prodDebugAPK

[RitikaPahwa4444]

I tested this branch as well as main, it does seem like a glitch at our end only. Sorry, by looking at the screenshots in the PR, I thought that's how we're providing the input.

On this branch, I'm getting this box at the end for every image I check:

[Salehcodes]

Screen_Recording_20260103_124428_Commons.mp4

As you can see here the description before pressing details button included raw html tags eg. <b> but after pressing details the tag was rendered correctly.

Ps. I did not upload this image this is real user image and input which I noticed that a lot of them in my area use html tags idk why.