(Poorly translated) error from JOSM that doesn't occur in the JOSM mapcss file listed as source

[Famlam]

The following warnings got my attention:
https://osmose.openstreetmap.fr/en/issues/open?item=9002&class=9002015
{{0.key}}={{0.value}} is unspecific. Please replace ''{{0.value}}'' by ''left'', ''right'' or ''both''.
Reason: someone translated it into Dutch and also translated the directions (which shouldn't be translated), so basically it now suggests to change the tag to sidewalk=rechts or so.
{{0.key}}={{0.value}} is niet specifiek. Vervang ''{{0.value}}'' door ''links'', ''rechts'' of ''beide''.

Example:
https://osmose.openstreetmap.fr/en/issue/b9c7d0a9-e08a-f320-99ee-19ec07f009c6

According to the error, it originates from https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator/deprecated.mapcss

However, this file from JOSM doesn't contain any warning with this exact string: the error thrown by JOSM is throwWarning: tr("{0} is unspecific", "{0.tag}");.
So this warning doesn't originate from JOSM, even though it's listed as the origin. However, the string doesn't occur in the Transifex translations either: https://github.com/osm-fr/osmose-backend/blob/master/po/osmose-backend.pot

So I'm a bit puzzled:

1. where it originates from
2. how to (fix the) translations

[frodrigo]

It is in https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator/deprecated.mapcss

But as "{0}={1} is unspecific. Please replace ''{1}'' by a specific value."

[Famlam]

That one is for different rules. The one for sidewalk=yes is a few lines below the one you quoted. But that's not the point.

The point is:

1. There's a different message shown than JOSM gives for this rule
2. This message is poorly translated (at least in Dutch)
3. But the translation doesn't occur in JOSM nor in Transifex.
4. So I cannot fix the translation either

[frodrigo]

You are right !

The class 9002015 is no more in source file. Delete here
3c0f320#diff-4e4b84d0cc64d3d08f73c8e946c90d7d13e63f786baa75cbc259f48f12b9887dL31

That a frontend issue. Since the backend does no more send update. The frontend does not know it has to delete the full class. But as linked to to an existing source (analyser) it show the last source update timestamp.

We may have other lost classes. Not sure how to make is list of lost classes, yet.

cc @jocelynj

[Famlam]

We may have other lost classes. Not sure how to make is list of lost classes, yet.

I think this may be a good start of disappeared classes: I checked with the item_map.py file which rules of the hardcoded classes are now gone:
https://github.com/osm-fr/osmose-backend/pull/1738/files#diff-aaadd0ad75cbfcb63cb1763a178018db45839ffa662294044cff31b0f8394666

(Also added a test to catch these automatically from now on)

[frodrigo]

Thank you for your PR, it is not what I was think about, but interesting to clean item_map.

My point was about cleaning the lost classes in the frontend.

[Famlam]

Correct, I phrased it a bit poorly, sorry about that. What I meant was that probably a good start to remove the items corresponding to the classes that I removed from item_map.py from the frontend too. That is, any error still existing on the frontend for any of the classes below, should be removed, because the related mapcss rule doesn't exist anymore either:
9018054, 9018060, 9018024, 9018061, 9018055, 9018015, 9018045, 9018040, 9018065, 9018001, 9018062, 9018050, 9018058, 9018057, 9018028, 9018011, 9018025, 9018059, 9018038, 9000002, 9000001, 9016027, 9016001, 9002010, 9002009, 9002022, 9002013, 9002008, 9002015, 9003010, 9003005, 9004003, 9004007, 9004005, 9006020, 9006018, 9006019, 9015003, 9015006, 9015029, 9015027, 9008001, 9008002, 9008004, 9008003, 9014014, 9014013, 9014018, 9014004, 9014015, 9014016, 9014003, 9014011, 9014017, 9014001, 9014012, 9011013, 9011014

[frodrigo]

Ok, thank you. I cleaned all this list classes.

[Famlam]

I don't think there's much to be done here in the backend, so I filed osm-fr/osmose-frontend#446 on the frontend for any remaining classes and/or future cases