Inconsistent Components Use in Worldwide Templates #116
Description
Hi,
I have observed inconsistencies in the worldwide.yaml templates and their use of components.yaml words. Using generic4 as an example:
generic4: &generic4 |
{{{attention}}}
{{{house}}}
{{{house_number}}} {{{road}}}
{{#first}} {{{village}}} || {{{hamlet}}} {{/first}}
{{#first}} {{{city}}} || {{{town}}} || {{{state_district}}} || {{{suburb}}} || {{{municipality}}} || {{{county}}} {{/first}}, {{#first}} {{{state_code}}} || {{{state}}} {{/first}} {{{postcode}}}
{{{country}}}
One of the aliases for house is building, however the template doesn't recognize that.
This means
house_number: 301
house: Visitor Center
road: Hamilton Avenue
neighbourhood: Crescent Park
city: Palo Alto
postcode: 94303
county: Santa Clara County
state: California
country: United States of America
country_code: US
returns
Visitor Center
301 Hamilton Avenue
Palo Alto, CA 94303
United States of America
However, switching out the house key for building:
house_number: 301
building: Visitor Center
road: Hamilton Avenue
neighbourhood: Crescent Park
city: Palo Alto
postcode: 94303
county: Santa Clara County
state: California
country: United States of America
country_code: US
returns an address without the corresponding house/building value.
301 Hamilton Avenue
Palo Alto, CA 94303
United States of America
Given that these are indeed aliases and therefore should be interchangeable, one could speculate that the template itself is lacking because it doesn't account for all of the possible aliases. Realistically, requiring a template to consider all aliases is overly verbose and doesn't make sense, but many templates' current use of default words versus their alias equivalents is inconsistent and leads to the behavior outlined above.
I also see templates that account for some alias variations, but not all of them. In generic9, suburb and city_district are both present; both of these are aliases to neighbourhood, which is not included.
generic9: &generic9 |
{{{attention}}}
{{{house}}}
{{{road}}} {{{house_number}}}
{{#first}} {{{suburb}}} || {{{city_district}}} || {{{state_district}}} {{/first}}
{{{postcode}}} {{#first}} {{{city}}} || {{{town}}} || {{{village}}} || {{{hamlet}}} || {{{state}}} {{/first}}
{{{country}}}
Possible Solutions
I would like to propose a couple of options:
- The templates could be reworked to only consider the default word and not any of the aliases. This means the end-users (ie. programming language specific libraries) are responsible for mapping the aliases to their default equivalent before passing the components along to the revised templates.
- However, if there's a reason why the templates were designed the way they are and should not be modified, then the end-user should copy the same value across all variations of that word's alias group for the current as-is templates to pick up on the different names. So, for
neighbourhood, its value would have to copied to aliases [suburb,city_district,commune,district,quarter,borough,city_block,residential,commercial,industrial,houses,subdistrict,subdivision,ward].- It's not enough to just have 2 copy values, aka between an input alias and its default equivalent. For example, if the input had
subdivision, and generic9 was being used, then a copied value forsubdivision(alias) andneighbourhood(default) would fall short because that template doesn't consider either of these keys; hence the need to copy the value across all aliases and the default, to accommodate for not knowing what the template uses.
- It's not enough to just have 2 copy values, aka between an input alias and its default equivalent. For example, if the input had
Please let me know your thoughts on the matter.
Thank you.