enhance display of boundaries in relation list dialog

[Klumbumbus]

I received this idea via a pm from a user.

all boundary relations display the text boundary (...) in the relation list dialog
This could be more specific by adding the boundary type from our presets.
Additional for boudary=protected_area the value of protect_class could be shown in [] like this is already done for administrative boundaries with admin_level

So the display of ​relation/5874542 could enhance from:

boundary (...)

to

boundary: protected area [4] (...)

(See also #12467 for related regression.)

[simon04]

We have a few options:

• define presets and use name_template, see wiki:NameTemplate
• add the most common ​boundary values to i18n/specialmessages.java and enhance org.openstreetmap.josm.gui.DefaultNameFormatter#getRelationTypeName (similar to type=place)

[Klumbumbus]

Replying to simon04:

• define presets and use name_template, see wiki:NameTemplate

Wow. I didn't know this exists. Using JOSM for several years and still discovering great features :)

Which of the two methods is preffered?

I case of first method: we already have presets in Geography/boundaries/*

I played a bit with name_template and this is the result (for the protected area boundary):

name_template="Boundary: Protected Area ?{ protect_class=* '[{protect_class}] ' | ''}"
name_template_filter="boundary=protected_area"

Seems to work fine. Any improvements? The whole page wiki:NameTemplate is a bit confusing and hard to understand.

I'm not sure what is with i18n. Will name_template be a i18n string?

[simon04]

Replying to Klumbumbus:

Which of the two methods is preffered?

I don't know. DefaultNameFormatter is quite a mess with various special treatments (e.g., addr:*) mixed with two or more parallel user-configurable systems (such as the pref key relation.nameOrder and the preset name_template). It might be a good idea to move some parts to name_templates in the defaultprestes. Other opinions?

I'm not sure what is with i18n. Will name_template be a i18n string?

Not yet, but that could be added. The translators would be confronted with the name_template syntax, however.

[bastiK]

Replying to simon04:

Replying to Klumbumbus:

Which of the two methods is preffered?

I don't know. DefaultNameFormatter is quite a mess with various special treatments (e.g., addr:*) mixed with two or more parallel user-configurable systems (such as the pref key relation.nameOrder and the preset name_template).

I think it's not too bad. We might as well include protect_class as another special treatment, makes no difference. On the long run, I agree a text-file configuration would be better.

It might be a good idea to move some parts to name_templates in the defaultprestes. Other opinions?

I'm not sure what is with i18n. Will name_template be a i18n string?

Not yet, but that could be added. The translators would be confronted with the name_template syntax, however.

Probably overkill, but a new and separate MapCSS-based system would work better for translations, e.g.

relation[boundary=protected_area][!protect_class] {
  label: tr("Boundary: Protected Area");
}
relation[boundary=protected_area][protect_class] {
  label: tr("Boundary: Protected Area [{0}]", tag("protect_class"));
}

[Don-vip]

the name_template approach sounds good. I did not know it neither, as it is not used in default presets. That's a good opportunity to use this feature and make it more visible to our users.

[Don-vip]

Milestone renamed