I noticed that the formatting (specifically whitespace) on the profile pages in the android app is removed. Many people have lengthy profile descriptions with paragraphs to break it up. They display fine on the website, but in the app it is just one long block of text with no line breaks. This can make it pretty difficult to read.
I just altered the title of the bug report because I realized it isn’t just the profile pages that are impacted. The comments also display with line breaks removed in the app. So what looks like nice neat paragraphs on the website is just one giant block of text in the app.
Also URLs that are in the observation notes or description section are automatically made into hyperlinks on the website, but they just display as plain text in the app. URLs in the comments section of the app are actually shown as hyperlinks however. So there’s some inconsistency in how text formatting is handled in the app. This is the Android app.
I don’t think either of these are bugs - they’re how the app is intended to work. These would be as feature requests.
It’s the inconsistency that makes me think it’s not intentional. Maybe “bug” is a strong word, maybe more of an oversight? The profile, observation notes, and comments are all user created text. If it was intentional and by design I would think it would be treated the same in all three areas in the app. Having long blocks of text with no whitespace is difficult to read. The fact that they display properly on the website indicates the formatting is stored with the text in the database, but it’s either being stripped out or just not handled consistently in the app.
I have a hunch that it might also depend on if the user created the text in the app or on the website, since I did see a couple of profiles displayed in the app where there was whitespace and text formatting as expected.
Links and screenshots would be really helpful here. FWIW, we’ve been supporting Markdown in obs descriptions, comments, user profiles, and elsewhere since this spring, which I suspect addressed most of the problems raised here, but if not, please provide some concrete counter-examples.
