- Not useful to majority of users and clutters the UI
- Anyone interested in translation will already be looking at the iD
project and we can direct them from there
- Previously caused minor unexpected renderer behaviour by forcing elements
visible when the user had moved on (potentially interfering with
whatever they're currently doing)
- ES6ify (now using class syntax to define QAItem objects)
- Fix bug with KeepRight marker rendering not updating properly
- Use `qa-` prefix for the UI element classes to differentiate from iD
validation error related UI element classes
- Move away from "error" where possible in source
- Move away from snake_case naming where possible
Note that some function/method names have been untouched to make life
easier for v3 development. Have added note comments where appropriate.
- Remove translation description strings, will be using supplied
translations once the API is updated
- Change the way elements and details are presented since they can't be
easily integrated into the 3rd party description strings
This is just step one in the process while we wait for the API to supply
further strings and filtering to reduce the amount of string data
requested (since we don't need it all).
Strings are requested when the layer is first enabled and cached for the
current language (plus English as a backup).
Also marked the `closed:` tags as readonly since these are filled in
automatically.
- Gives a count of each error type closed instead of making a list of
joined coordinates which quickly fills the maximum value length.
- This is more useful since a changeset already gives the area worked
on while these counts give insight into the type of changes made.
- Similar to iD own validation tags
This seems more useful than tagging with a list of joined coordinates
which quickly becomes truncated due to tag value length.
Adds a tag per issue type similar to iDs own validation.
- Simplifies our code a little bit
- Quick to provide and gives us the `item` + `class` without requesting
all other information (the two things needed to know the error type)
- Removed handling of associated elements for now, need to implement
fetching for that data on a per-issue basis when the UI loads
- Set things up for the possibility of using the provided translation
strings (need to determine if desirable)
See: https://github.com/osm-fr/osmose-frontend/issues/193
Some error types don't require unique strings and can share common
strings among the category. This makes that possible as well as adding
support for some other types of error for demonstrative purposes.
