Localize the types throughout the app

[wbazant]

As part of #204 epic, localize the types in the app.

The proposed strategy for locations without common names in another language is to show just the scientific name. When displaying a scientific name, it should be italicised as is customary on science websites.

To test, set language to French. Make sure these show up in French in the app:

Main page:
http://localhost:3000/map/@55.8268950,-4.2611486,17z
types checkbox on the left
labels on the right

Location:
http://localhost:3000/locations/1989068/@55.8268950,-4.2611486,17z
location header in the side pane
location header in "report"

Edit location:
localhost:3000/locations/1989068/edit/@55.8268950,-4.2611486,17z
tags in the cloud
list in search

Mobile drawer:
http://localhost:3000/locations/1989712/@55.8268950,-4.2611486,17z

Mobile list view:
http://localhost:3000/list/@55.8260021,-4.2610245,17z

Mobile edit position:
localhost:3000/locations/1989068/edit/@55.8268950,-4.2611486,17z
go to position and back, check the labels are preserved

Also check with a location that doesn't have a common name in French e.g. http://localhost:3000/locations/1819648/@42.3910266,-72.5284893,14z

[wbazant]

Just looking at #416

Fall back to English if no common name found in selected language. Adjust layout when no common name.

I want to clarify, I've fell back to just the scientific name - the English names in e.g. Polish setting of fallingfruit.org feel quite janky, and give a feeling of a very incomplete translation - and think it's a better solution but we can change this!

[ezwelty]

Fallback to English is the behavior of the current website, which made more sense back when an English common name was required for all types. This is no longer the case (many plants that don't grow near English speakers don't have a common English name). Having no fallback leads to a lot of emptiness, but this could be fixed with better automation: I have code for scraping common names from Wikipedias and other places, and should consider rerunning to fill in names for new types. And I've considered propagating names to child types, perhaps by the API or by the client. Right now e.g. the type for Pyrus communis has a lot of common names, but most of it's cultivar children do not, although obviously using the parent's names in this case would be adequate. Beyond more complete common names data for a single language, I suppose the ideal would be make the fallback / display language(s) configurable? I still believe scientific name should remain displayed always, because the type tree just doesn't make sense without it.

…

On Thu, Aug 29, 2024, 18:57 Wojtek Bażant ***@***.***> wrote: Just looking at #416 <#416> Fall back to English if no common name found in selected language. Adjust layout when no common name. I want to clarify, I've fell back to just the scientific name - the English names in e.g. Polish setting of fallingfruit.org feel quite janky, and give a feeling of a very incomplete translation - and think it's a better solution but we can change this! — Reply to this email directly, view it on GitHub <#434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC4FMZVB4TJ4ORGVTUMIUDZT5HG7AVCNFSM6AAAAABL65GYUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJYGM3TKNRVGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wbazant]

This is live and mostly working as I intended, if I understand you correctly, we're in agreement about the fallback being just the scientific name. The strategy of scraping the translations sounds like a reasonable plan to gradually improve the experience in other languages. I'm going to fail the QA on the extra white space that should be removed:

[ezwelty]

I'm going to fail the QA on the extra white space that should be removed:

There is an open issue for that, so closing this one.
#473