<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">placing a localized version of the name tag in front of the <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
corresponding language area is still an option I support.  Red Sea would <br>
be a nice test-bed, just like the Ostsee.<br></blockquote><div> </div><div>The problem I see with this is that it violates the 'one feature one element' principle. The labels would probably need to be tied together into a relation to avoid this and that then starts to get very complicated very quickly. You also don't know if you're looking at multiple separately named regions or one large feature with multiple translations. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Adding a language name to the URL schema does not look so difficult to <br>
me, what's going to be difficult is paying the money needed to hold the <br>
data.<br></blockquote><div><br></div><div>I think the cost implications mostly go away with vector tiles as you are essentially "rendering" client side and the additional server side load is (allegedly) minimal. Browser support and processing power on the consumer side can then start to be an issue as it's not as trivial to display as a simple image. From my limited viewpoint the greatest risk I see from vector tiles is that the capacity for abuse skyrockets as the client side customisability might lead some to think "this is like Mapbox but free" and just pull from <a href="http://openstreetmap.org">openstreetmap.org</a> instead of using a proper service. </div></div></div>