[Tagging] Slash, space, or spaced hyphen in multi-lingual names

Paul Allen pla16021 at gmail.com
Fri Aug 10 22:39:32 UTC 2018


On Fri, Aug 10, 2018 at 10:47 PM, Peter Elderson <pelderson at gmail.com>
wrote:

if I were a renderer I would not try to parse/interpret a free format
> string. I would parse only clearly defined sections, where the separator is
> very very unlikely to occur in text strings. Space slash space might be
> suitable, but not if any context is required, context such as that it’s
> about language. So even if mappers and taggers decide to use eg
> spaceslashspace as a language separator or whatever other category of
> separator, I would still just render the full string including the
> separator string.
>

Indeed.  Don't parse it.  It's not intended to be parseable and more than a
variable name in a computer program.  It is
a label with no intrinsic semantics.  Well, there's a separator which may
not be present on the actual sign (but see
below).

As a mapper, I want to map whats visible on the ground. Street names are
> visible as strings on signs. I want to enter those without having to
> consult other sources. If I happen to have more detailed knowledge, I want
> to enter that in addition to the basics, not instead of.


Indeed.  In my opinion that is the true purpose of name:xx=*.

There is a separator which could be used (if editors permit) which is
present on some signs.  That is a new line.  Not
every bilingual sign has a new line.  Not every new line on a sign
separates languages (it could be a multi-word
name on a sign which has to be narrow because of space restrictions).  But
it's a separator that could be entered as-is
and is guaranteed to mean nothing more than that the sign has a line break
at that point (which may also be the end
of one language and the start of another).  Use name:xx to make it clear if
different portions of the sign are in different
languages.

If (still as a mapper) I see multiple lines with equal font
> style/type/size, then I would probably summize that they are equal
> variants. In bilingual areas you can often be quite certain. Then I would
> concatenate using slash or space slash space. I would expect the renderer,
> any rendererer, not to break up the string but just render the whole thing
> as the name. Of course when name:xx tags are present, renderers may have
> rules for preference regarding name tags.
>

This is a different problem from which separator to use.  But it is sort of
tangled up with that.  I live in Wales which is
officially bilingual English/Welsh.  But it's not uniform.  There are parts
of Wales where most of the population is
bilingual with a small percentage understanding only Welsh and a small
percentage understanding only English.  In
other parts of Wales almost everybody understands English and almost nobody
understands Welsh.  Some renderers
assume that Wales is uniform and where name:cy exists it should be used in
preference to name:en or name.  Other
renderers give preference to name:en over name.  Both approaches have
problems over always preferring name (if
present).

Name is (should be) what is present.  Somebody who speaks only Welsh and
somebody who speaks only English
can both live with "Aberteifi / Cardigan."  Especially if both forms appear
on road signage together (they usually do).
A renderer preferring name:cy or name:en is going to upset or confuse more
people.


> If I were a data user, again I would not try to do anything with
> substrings of a free format string. Which is not the same as being against
> whatever people may wish to put in it, just you don’t build anything on
> free format strings.
>

That's what name:xx is there for.  It's still a free-format string, and
therefore unparseable, but it's in a particular
language

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180810/96e5cc85/attachment-0001.html>


More information about the Tagging mailing list