The new replacement bilingual signs essentially do away with the drive or promenade part of the name.  On a street sign saying "promenade Wilkie Drive" Wilkie is roughly four times the font size than the two other components.  The street sign also lists the house numbers, should they be part of the name since they appear on the street sign?<br>
<br>I think we have to be pragmatic.  In Ottawa's internal systems they don't even use the Drive or Promenade part of the name.  Example <a href="http://apps104.ottawa.ca/emap">http://apps104.ottawa.ca/emap</a>.  Currently most Ottawa street names are tagged with English in the name field.  This is consistent with the wiki <a href="http://wiki.openstreetmap.org/wiki/Bilingual_street_names">http://wiki.openstreetmap.org/wiki/Bilingual_street_names</a> note Ireland and Japan.  When a European, German for example, gets into a rail carriage in a different European country they will normally ask in English  "Is this seat taken?"  Currently we do not have renders that vary the font size to match the street sign.<br>
<br>When you do a search the search will use the name field first to find a match.  The UK has a search that works on UK Postcodes with a space in the middle, this doesn't work on Canadian Postcodes, the person who built the search engine is in the UK, Canadian postcode searches are not a priority to him.  It is easy to build code that sees if the street name being searched for matches the beginning of the street name.  Wilkie matches Wilkie, if its Drive or Dr. we don't really care.  Especially in Ottawa where there will only be one Wilkie.  It is much more difficult to build one that parses the name and removes any "promenade" or "prom." or other variant from the front before trying to match the name.  OSM has multiple demands on programmers time, realistically our chances of getting something special just for one city of a million people are very low and personally I'd rather see Canadian postcodes search-able first.  You also have to think of end users, how many wourld be willing or even capable of entering "promenade Wilkie Drive" correctly spelt?  I suspect they are more likely to turn to Google.<br>
<br>Should we ever get to the point of having renders that can put the street name in a font that is four times the size of the word "Drive" etc. and have search engines that can parse oddly inserted names then we can always run a bot down the file and shuffle things around into your three tags.<br>
<br>name=Promenade Wilkie Drive<br>
name:en=Wilkie Drive<br>
name:fr=Promenade Wilkie<br><br>For the moment though I suggest we follow what has been done so far and add the French name under "name:fr=promenade Wilkie" note the small p.  That way we can display the street names in French to a francophone which is a great step forward over what is available today.  It also takes less room up in the database and as some one who worked in assembler for ten years when data storage was expensive this has performance / cost implications.  Additionally the more fields you have the more chance that the data will become inconsistent.  What do you do if the three fields have different values?  Perhaps because of a bot that doesn't know about your local rules.  After working with large databases at Stats Can for a number of years my professional opinion would be to minimise the number of tags to avoid then type of error.<br>
<br>A comment from Canada Post that came from a working group I was in "Do not translate addresses."  They gave an example in Calgary where there were a number of English endings such as road, way, drive, etc that came to the same French translation.<br>
<br>Cheerio John<br><br><div class="gmail_quote">On 12 May 2010 22:13, Richard Weait <span dir="ltr"><<a href="mailto:richard@weait.com">richard@weait.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Wed, May 12, 2010 at 9:44 PM, john whelan <<a href="mailto:jwhelan0112@gmail.com">jwhelan0112@gmail.com</a>> wrote:<br>
> I've put in what I think might be useful to newcomers about what data to<br>
> enter and why.<br>
><br>
> <a href="http://wiki.openstreetmap.org/wiki/WikiProject_Canada#Canadian_best_practices" target="_blank">http://wiki.openstreetmap.org/wiki/WikiProject_Canada#Canadian_best_practices</a><br>
><br>
> Perhaps some one could look through it and comment or amend.<br>
<br>
Are there bilingual road signs in Ottawa?  If a sign said "Promenade<br>
Wilkie Drive" I'd use<br>
<br>
name=Promenade Wilkie Drive<br>
name:en=Wilkie Drive<br>
name:fr=Promenade Wilkie<br>
<br>
Other examples are Federal buildings, which even here in Toronto have<br>
bilingual signs.  The Parliament Buildings in Ottawa are named as<br>
<br>
name=Parlement du Canada / Parliament of Canada<br>
name:en=Parliament of Canada<br>
name:fr=Parlement du Canada<br>
<br>
Bilingual maps are a recent interest of mine.  I have a French<br>
language OSM now running in-house here.<br>
<br>
One thing I notice is that while rendering the World with name:fr,<br>
Quebec and France are almost empty!  They use name, as they should but<br>
not also name:fr.  The same is true of name:en and probably many other<br>
languages.  It looks a bit funny to see Edimbourg, Londres and<br>
Copenhague, but Paris is missing!<br>
<br>
This is not insurmountable.  It is possible to preferentially show<br>
name:fr and fall back to name if name:fr is empty.  It even possible<br>
to default to name in Quebec, and use name:fr elsewhere and either<br>
fall back, or not.  And I suppose I would make each of these rendering<br>
choices, depending on whether I want to show a lot of names, or<br>
emphasize missing data with blank spaces (to encourage updates).<br>
<br>
Thoughts?<br>
</blockquote></div><br>