Tree names in different languages

[westnordost]

I read that SCEE has some functionality to add/edit the species/genus of trees, awesome!

Now, a useful addition to that would be if SCEE would be able to recognize which localized tree name relates to which international (i.e. Latin, not English) species/genus name, so to be able to...

• always show the localized name (too) to avoid misunderstandings. E.g. it would be nice if a "Quercus" is shown as "Oak" if your locale is English
• detect which wikidata ID relates to which species/genus to also properly display a name. E.g. nobody understands what a Q165145 is, but everyone understands what an "English Oak" (Stieleiche in German, very common in cities) is.
• detect conflict errors
• (maybe) always default to tagging the Latin name? (Or, otherwise maybe not encourage double/triple-tagging, i.e. localized name+latin name+wikidata id because that's such a pointless waste of time!)

Now, I also read in the readme that...

Allows providing a file containing translated tree names instead of the default English ones

No need for that! Check out this wikidata query, and this is the reason why I posted this idea:

SELECT DISTINCT ?item ?itemLabel ?taxon_common_name WHERE {
  ?item wdt:P171+ ?taxon .
  ?taxon wdt:P279 wd:Q10884 .
  ?item wdt:P1843 ?taxon_common_name.
  
  FILTER (lang(?taxon_common_name) = "en") .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}

Try it out!

This could be a build script, one query for each available language.

[westnordost]

By the way, at least the "displaying the localized name of a tree" would be useful on vanilla StreetComplete, too, as an enhancement for the "things overlay" but overall a tree overlay like it exists in SCEE is going to profit a lot more from that.

[Helium314]

Currently there is no overlay (except maybe a custom overlay), but a quest that asks for tree genus / species.
Still the tree species is displayed in the nearby elements in that quest.

Thanks for the query, this should be really useful. I remember I had tried to find some source for latin <-> <language> names, and only found proprietary stuff. But apparently I didn't think of wikidata!

(it will still be a while until I start working on this, currently it feels like I'm drowning in app-related work)

[westnordost]

Doesn't the tree layer of MapComplete use exclusively wikidata to tag the species? Not sure, but I think I read something like that once. So being able to translate wikidata tags will also be very useful.

(it will still be a while until I start working on this, currently it feels like I'm drowning in app-related work)

Sorry to hear that, I bet I am somewhat to blame for that, since I completely re-did the settings screen to which you certainly made a few additions. Feel free to ask me about it or ask for help, you got my email and phone number after all. I am also in the slack OSM chat. Or @ mention me in discussion/forum etc. (E.g. if you have any setting in the app which requires a number picker - a number picker dialog would need to actually be implemented first - there's nothing built-in yet. But I already did a bit of research and implementation would be... not that many LOC.)

And anyway, I posted this here rather than as an issue because it should not be a TODO but an idea, which really anyone could implement, e.g. people interested in that tree quest / overlay.

[Helium314]

And anyway, I posted this here rather than as an issue because it should not be a TODO but an idea, which really anyone could implement, e.g. people interested in that tree quest / overlay.

I think it would be a very useful improvement for the tree quest, and I already put it on my own todo list.

Sorry to hear that, I bet I am somewhat to blame for that, since I completely re-did the settings screen to which you certainly made a few additions

Somewhat, but it already was bad way before I tried merging the new settings screen.
Most of the SCEE settings are in separate settings screens, so if I can still use them it might not be much work.

@ravenfeld has offered to help here, and also sent me this link on how I could keep the old settings screens.
If this works out, the only thing that must be re-done is the per-quest settings, which are an addition to the quest selection screen.

But I guess soon there is more to be re-done in compose anyway, so avoiding the re-write is only a short-term solution.

[westnordost]

Most of the SCEE settings are in separate settings screens, so if I can still use them it might not be much work.

Right, hmm. But the whole Settings Activity is now Compose-based. Since your settings are likely in an own Fragment, and a Fragment is not really a View, it can not easily be embedded in a Compose-based view. As far as I know. Didn't look into that yet.
Hmm, but ... if you don't want to migrate the screen to Compose (which might ultimately be less work, but your choice, of course), you could try the following:

1. Add parameter onClickSceeSettings: () -> Unit to the SettingsScreen and invoke it when clicking on the item that opens the SCEE settings
2. hoist that parameter up in the Settings navhost, i.e. it is also a parameter there
3. Finally, in the Activity, i.e. the class that contains the NavHost, you get that callback and can do whatever, e.g. add the SceeSettingsFragment as a child fragment which will display above the compose-based settings.

[Helium314]

Thanks, the old settings screens are now working. So at least I can do the settings migration later when I have more time.