Add translatable strings to kerb field

[kjonosm]

No description provided.

[github-actions]

🍱 Preview the tagging presets of this pull request here: https://pr-1029--ideditor-presets-preview.netlify.app/id/dist/#locale=en.

[kjonosm]

Hi @tyrasd, would you be able to review this pr?

[tyrasd]

I think this needs a little bit more polish, to be honest. Here are a few thoughts:

• A new mapper will not really know the concrete distinctions between flush and lowered and raised. That should be made discoverable, at least in form of tooltips, e.g.

  …
  "strings": {
      "options": {
          "lowered": {
              "title": "Lowered",
              "description": "A dropped curb which can be used by wheelchair users, not higher than a few centimeters."
          },
          …
      }
  }, …
  ```

• the values yes and no are not really applicable in the preset for barrier=kerb (yes would be redundant, and no would be a contradiction). These values would however potentially make some sense when the tag is used as a property of a highway=crossing node. Currently, the presets share the same kerb field, but when we add the options, the field would need to be duplicated for the two cases: one with all options (for the crossing preset) and one without yes/no (for the kerb presets).

[kjonosm]

one with all options (for the crossing preset) and one without yes/no (for the kerb presets).

How should the corresponding json files be named? And should the field for the kerb preset go into the .../fields/kerb/ subfolder?

[tyrasd]

I would mimic the way we did this for the different sport fields (see e.g. sport_racing_motor.json for an example) and use these files:

• keep the existing kerb.json with all strings/options in the root directory data/fields
• a file kerb_barrier.json in the subfolder in the subdirectory data/fields/kerb/

[tyrasd]

Thanks, this looks good now!