<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 10, 2018 at 10:47 PM, Peter Elderson <span dir="ltr"><<a href="mailto:pelderson@gmail.com" target="_blank">pelderson@gmail.com</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>Indeed.  Don't parse it.  It's not intended to be parseable and more than a variable name in a computer program.  It is<br></div><div>a label with no intrinsic semantics.  Well, there's a separator which may not be present on the actual sign (but see<br></div><div>below). <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>Indeed.  In my opinion that is the true purpose of name:xx=*.<br><br></div><div>There is a separator which could be used (if editors permit) which is present on some signs.  That is a new line.  Not<br></div><div>every bilingual sign has a new line.  Not every new line on a sign separates languages (it could be a multi-word<br></div><div>name on a sign which has to be narrow because of space restrictions).  But it's a separator that could be entered as-is<br></div><div>and is guaranteed to mean nothing more than that the sign has a line break at that point (which may also be the end<br></div><div>of one language and the start of another).  Use name:xx to make it clear if different portions of the sign are in different<br></div><div>languages.<br></div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>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<br></div><div>officially bilingual English/Welsh.  But it's not uniform.  There are parts of Wales where most of the population is<br></div><div>bilingual with a small percentage understanding only Welsh and a small percentage understanding only English.  In<br></div><div>other parts of Wales almost everybody understands English and almost nobody understands Welsh.  Some renderers<br></div><div>assume that Wales is uniform and where name:cy exists it should be used in preference to name:en or name.  Other<br></div><div>renderers give preference to name:en over name.  Both approaches have problems over always preferring name (if<br></div><div>present).<br><br></div><div>Name is (should be) what is present.  Somebody who speaks only Welsh and somebody who speaks only English<br></div><div>can both live with "Aberteifi / Cardigan."  Especially if both forms appear on road signage together (they usually do).<br>A renderer preferring name:cy or name:en is going to upset or confuse more people.<br></div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br></blockquote><div><br></div><div>That's what name:xx is there for.  It's still a free-format string, and therefore unparseable, but it's in a particular<br></div><div>language<br><br>-- <br></div><div>Paul<br><br></div></div></div></div>