Language Decision and Tile URLs

Whatever way we’ll develop for rendering the multilingual tiles, we have to get the information about which language(s) the user wants from the user to the tileserver. Web browsers typically support the selection of an ordered list of preferred languages. This list is sent through the Accept-Language header to the web server. We could use this setting to determine the language for the labels. But in some situations people might not know about this setting or can’t change it. Maybe they are sitting in an Internet cafe in a foreign country. In that case it might be easier for them if they can just change the language setting on the web page. This is especially interesting if the web site knows which languages are available and only shows those options. The browser setting doesn’t know anything about actually available languages, it just has one large master list.

So we probably want the default to be the browser setting and the user can override this on the web page itself. This is how it is done in many web pages. If the user sets the language, we could either store this information in a cookie or we can put it in the tile URLs. If it is stored in a cookie the server would have to read the Accept-Language header and the cookie and determine the desired language from those settings. Instead we could aggregate the information from the Accept-Language header and the user setting inside the browser into one setting and put that into the URL.

Having the language choice in the URL has several advantages: It is easier to use the tiles for everybody not using a normal browser. Say, you request tiles from the command line with wget, or maybe from some specialized program. It is much easier to just use the URL instead of setting an Accept-Language header and a cookie. There is also the question of caching. Do all caches which might be between the server and the browser and the cache in the browser know about the Accept-Language header and the cookie and take them into account? If all information is in the URL, we do not have to think about that.

So how is the URL going to look? Lets look at a “traditional” tile URL first. Typically there is a prefix, the map style, the zoom level, x and y coordinates and the file type in the URL. Something like this:

/tiles/osm/3/2/1.png

The prefix (/tiles/ in this case) basically tells the server that there is a tile here, it can be empty in some cases, but might be needed in others if the same server is used for other web content, too. The map style parameter (here osm) is configured in the server and will lead to the right Mapnik style being loaded. The other parameters are pretty much self-explanatory.

We could put the language choice in the style slot, but then we can not have different styles for the labels. And we probably need a fixed list of languages, because existing tile server software needs this parameter to be pre-configured. We could also add it the end after a question mark: /tiles/osm/3/2/1.png?lang=en,de. That might be problematic for caching again, as some caches might think that URLs which such parameters can not be cached.

But we can always just add another path element somewhere in the URL: /tiles/osm/en,de/3/2/1.png. Unfortunately we don’t have a good way of asking for the default language, because leaving this element empty leaves two forward slashes after another which might be confusing.

We can always extend this scheme to allow other parameters, too. Say for choosing the tile size: /tiles/osm/en,de/256/3/2/1.png

This might not be the prettiest URL ever, but it’ll do. We could argue about the order of the elements, maybe putting the language after the coordinates, but that doesn’t really matter. A variant might make it more clear that those parameters are basically parameters to the style: /tiles/osm;en,de;256/3/2/1.png or something like it. But it is not all all clear whether that makes things easier or more difficult.

We should probably keep the image format in the .png form, because this allows software that doesn’t have access the the Content-Type header to infer what format the image might be in.

One variant would be to name the attributes, something like .../lang=de,en/style=osm/... but this is longer and invites re-ordering of those elements which would not work well with caching so it shouldn’t be allowed.

Of course after we have decided on a URL format, we need to think about how to get all this information in the URL through the render stack into the renderer, but I’ll keep that problem for another blog post…

PS: There is a Web Map Tile Service Implementation Standard that describes how tile URLs should look like. But it comes with a lot of baggage and isn’t widely implemented. And it doesn’t seem to address the problem of extra arguments. So I’ll ignore that here.

Comments can be directed to the Multilingual maps wiki page.