Photo of Terence Eden. He has a beard and is smiling.

QRpedia - Dealing With Missing Entries

· 27 comments · 250 words

QRpedia is designed to offer a single QR code which points to the same article in multiple languages.

The most common question about QRpedia is "What does it do if the article doesn't exist in my language?"

Consider the following example...

  • A French user is in a German museum.
  • They scan a code - which points to de.qrwp/Nelahozeves
  • Unfortunately, Wikipedia doesn't have the "Nelahozeves" article in French
  • What should QRpedia do?

Choices

This has been a matter for much debate in the QRpedia team. I would greatly appreciate your thoughts on the subject.

As we see it, our choices are...

  1. 404 - Tell the user that the page doesn't exist.
  2. Wrong Language - Show the French user the German page
  3. Choice of Language - Show the French user a choice of German, English, Dutch, etc.
  4. Smart Search - Search French Wikipedia for the term, display the results to the user.
  5. Latin - Omnis intelligit Latinum. Si non sunt barbarus!

At the moment, we do the smart search. In this case, we point to the French Wikipedia search for Nelahozeves - which has a couple of relevant results.

This isn't ideal. Often there are no suitable results - especially as we are searching French Wikipedia for a German word or phrase.

So - over to you. What should we do? Please leave your comments and suggestions.

Share this post on…

27 thoughts on “QRpedia - Dealing With Missing Entries”

  1. Holger says:

    What would be most useful for the reader? Certainly not option 1 and 5. Option 4 may be nice, but I already got stuck at the search page and there was no way to get back to the original language (my mobile opens a new tab, and there is no back-button since the search page is the first page in this tab). Otherwise we don't know what other language the user may prefer, he could be satisfied with an English article as well. I prefer a language choice which also includes the option to search the French Wikipedia. If there is no good result you could go back one step to the language choice and change yours. Btw: Are you using the Interwikilinks, or are you looking up if there is a similar named article on the other Wikipedia? Interwikilinks are often not used if there is only a redirect to a paragraph in another article.
    Reply

  2. says:

    I think I would prefer choice 3. If I don't get my primary language, a list of the available languages would quickest take me to the information that I could absorb. That list should also include a choice to take the original article and get a google translation into the phone's language.
    Reply

    1. says:

      Hi Jan, I really like the idea of redirecting to a translated page. I wonder how well Google Mobile Translate works on all phones. Russian QRpedia article automagically translated into English. I'm a bit unsure about serving a page to the user containing lots of links. a) That page would have to be translated into all the languages (at least the "Sorry, this article isn't available. Would you like..." b) Puts a lot of load on the server. But I'll take the idea on board. Thanks for the comment. T
      Reply

  3. Jo says:

    Personally, I think I would like the choice of language (or the wrong language). It's fundamentally annoying to be sent to content you didn't ask for. I don't especially want to learn about the Cité perdue du Kalahari in French. But I can do and the English alternatives in a search for 'the lost city of the Kalahari', though a perfectly respectable list of links are, crucially for me, not the piece of information I was actually looking for. In general, with their greater savoir faire (and grasp of languages beyond the lingua franca - or is that English?), I would expect our imaginary French visitor to be even more comfortable with an alternative European languages than myself, with my pitifully stunted French and German. I'm slightly more hesitant if the visitor is, say Japanese. An English alternative might be offered. What would be the next option? Is there a list out there of recommended "related" languages? What would a Russian like to see? Are Australians still encouraged to learn French or would they prefer Mandarin? I can see this could be thorny. So option 4 isn't what I would want for myself. But perhaps it's "better for the user"? (Whatever that means!)
    Reply

    1. says:

      Hi Jo, Good point - I will need to ask some international museum visitors what they think. As for related languages - that opens a whole can of political worms. Terence
      Reply

      1. says:

        Bear in mind, too, that languages != countries; so, say, a French speaker from France may have a different second-language preference to a French speaker from Belgium, or Canada (assuming only first-level, two-letter, language codes are specified).
        Reply

        1. says:

          Oh, I know! And there's no good way to represent a language. Showing the Stars and Stripes to indicate English is a good way to piss off a lot of people. I'm sure there are plenty of Francophones who identify with a language but not a specific flag. Interestingly, Wikipedia doesn't have a separate language for, say, Canadian French rather than Belgian French (I don't know if there is any significant differences).
          Reply

  4. says:

    While #4 is the best single option (and the one I suggested the last time you asked 😉 ), in an ideal world, I'd plump for a combination of #4, with a banner offering to do #3, and (#6) a reminder that the user may also (perhaps later) create the article/ add it to article requests. After all, Wikipedia needs more editors! Any or all of these could still be done under a 404 error code, of course (as en.wikipedia currently does for not-found articles). I appreciate that option #6 might mean crowd-sourcing a set of translations; Google Translate may suffice in the interim. Please let me know if I (a non-coder, alas) can help with any of this.
    Reply

    1. says:

      Thanks Andy, good points. I probably won't return a literal 404 - too many phone browsers see the error code and stop without showing the page. Technically, it's an HTTP 406 error - because the content to be returned isn't acceptable based on the language header. I think! I'll certainly let you know if I need anything. Terence
      Reply

  5. rik says:

    My first pass would be: - Is there an article in the user's transmitted native language? If yes, return in order of their preference, and stop. - Is there an article in the language of the country the request is transmitted from? If yes, add to the head of the list of options and continue processing. - Is there an article at all? Add to the tail of the list of results. - Return the list of results. There's basically only a limited number of things you can do here, and when you know you don't know, you need to be as helpful as possible. I think it's not unreasonable to assume that since someone is in a country they probably have a grasp of the language - it may not be enough to understand everything though, so to me it seems to a "we think you'll probably want this, but we don't know" is probably the way forwards. Essentially, it's showing the search results in the order in which you're expecting the user to probably go for them. Most helpful with least impact when you're wrong is probably the mantra here.
    Reply

    1. says:

      Excellent points. My reservation about returning the country's language is that it may put the user off from scanning more codes. If the first code our mythical French woman scans leads to a German page, she may not want to scan any more - even though the majority will work in French. Despite my apprehension, it looks like creating a page with choices may be the best way... Terence
      Reply

  6. says:

    So, five comments so far - has got me seven suggestions! There is, as ever, a "correct" way to do this. The accept-language header can contain a list of languages in order of preference. e.g. 
    fr,fr-fr;q=0.8,en-us;q=0.5,de;q=0.3
    Which says "Show French, if not, American English, if not, German." Of course, there are close to zero phones which support this and, I suspect, even fewer users who would have bothered setting their phone up for such an occasion! Please keep the suggestions coming in.
    Reply

  7. Magnus says:

    Hello, QR-pedia is fantastic, one of few applications were QR-codes make sense! Of the options I would prefer number 3 and then number 2. ¨ With an apologetical text aqdded to option 3 if possible. When I scan at the moment I get option 1, i.e. the phone tries to search swedish wikipedia with the original article name, so even if the article would exist I guess it wold not find it?
    Reply

    1. says:

      Hi Magnus, That's right. Usually searching brings up something - especially if it's a person's name like "Jane Austen". But when it's not, it fails totally! T
      Reply

  8. says:

    Hi all, (Ive used an analogy here - imagine you scan "La Jaconde" (the Mona Lisa) in the Louvre with an English phone and there is no "Mona Lisa" article on the English Wikipedia) We started off QRpedia with just doing a 404 page when it could find not article, but I thought the near optimal solution (we moved onto) of doing a search for "Mona Lisa" when you could not find an article called "Mona Lisa" was the best we would find. The reason why I thought this was a near optimal solution was because it is the solution that Wikipedia itself uses when you cannot find an article. And they have been improving it for 10 years or so. If you are lucky Wikipedia finds you "Mona Lisa" in the "Louvre" article or "Mona Lisa" in the "Leonardo da Vinci" article and thats a fair solution. However in the QRpedia case we actually have more information available to do the search than you when you use Wikipedia. When you search Wikipedia for "Mona Lisa" then the search engine has just the 9 characters in the phrase "Mona Lisa" to do a search. It can be quite a silly solution as if it wasn't for other stuff that we add then it would throw up "Mona Lisa ( the film) etc". In the case of a QRpedia search however for "Mona Lisa" we actually know which object we are talking about because we know that the QR code points at Mona Lisa/La Joconde which is a painting. There is no doubt we are actually defining a particular object and a particular article.... in this case that article is missing. Therefore I think that automated translation is the best solution assuming we can label it as being as not being the genuine article. It also means that you can tour around a museum where there are few (or even no) articles in your language. It could be said that QRpedia in this case is adding very little if there are no articles in say Vietnamese and we are always doing an auto translate. However the QRpedia code is not telling you that this item has the name "Mona Lisa/La Jaconde". Because the QRpedia code is linked to a particular object on a particular wikipedia then we know that this translation relates precisely to this particular object, The QRpedia code will ensure that you never get "Mona Lisa the film" but you get an article that refers to the object in front of you. I suspect Ive lost most people with this analogy. In sumnary. I think auto translation is the best solution if we label it as such. With skill we can leave the auto translate article so it still has links in the article that allows the visitor to click to the "Louvre" or the "Leonardo da Vinci" article from the auto translation. What we ensure with this solution, is that we do not offer articles that are merely spelt the same but options that relate to that precise object. I think this is a surprising advantage that I never anticipated would be possible.
    Reply

    1. says:

      Thanks Roger. Do you know if there's an automated way to tell Wikipedia that an article should be translated? What I mean is, if I'm constantly sending Japanese people to an auto-translated "King of Rome" page - how can I notify Wikipedia that it is a high profile candidate for translation? Or will the Wikipedia logs pick up the referrers from Google Translate and look into it themselves?
      Reply

      1. says:

        You could create a Bot which, say, once a month adds a comment to the talk page of the article concerned, with the number of unsatisfied other-language requests; and perhaps a tracking category. such bots require community approval, but I don't think that would be an obstacle. Better still might be to add a note to a relevant page on the version of Wikipedia in the language of the missing article. Again, this may require a knowledge of several languages. Another option is to create a Project on (English) Wikipedia, with both sub-pages where such lists could be posted; and a discussion page where other editors might be solicited for ideas and practical contributions. As beofre, I'm happy to help with any of this.
        Reply

    2. says:

      +1 to Roger's point. I think that option #3 + auto translation button should be -for me as a museum visitor- the best option. And if - don't know how- the telephone remember my selection for next qr codes...then it would be great.
      Reply

  9. says:

    Personally, I'd prefer option 3 with an option for the user of doing 4. While I realize that English dominance might be sensitive I'd suggest when doing 3 of putting the English equivalent article link at the top. It's just a fact that English is globally the largest second language known. I'm assuming now that there are no means to catch user language preferences via cookies or active settings? BTW, not that the Google Translate API will become a pay for API on December 1st. The Google Translate widget though will remain free. Microsoft's translate API is also free and seems equally/nearly as good (based on anecdotal evidence).
    Reply

    1. says:

      Hi David, It may be worth putting Mandarin and English at the top - but then you get in to all manner of cultural sensitivity issues. I think the safest way is to list everything in alphabetical order (which, I know, has its own set of issues - but it how Wikipedia does it.) I could set a cookie - but that has two main issues. 1) Privacy 2) If a user mis-clicks on Japanese when they meant Dutch - how do they get back to change their preference? Thanks for pointing out about the Google Translate API. I think I'm right in saying that translate.google.com/m is still going to work after that date though? T
      Reply

  10. says:

    Agree on the general consensus here that option 3 + Google Translate option may be best. It's also true that option 2, sending someone to the wrong language, would certainly deter them from scanning any other codes, especially if they're frustrated by the language they were sent to. I fear I can offer no help in regards to the technical logistics behind how to list them or which languages to suggest, etc. But (hesitatingly) agree that English should be towards the top of the suggestions, if only because the article will more than likely exist there and then can be google translated if needed. Sorry to take so long to reply. I've recently learned that we need to get some Russian translations up, stat! Thanks again for everything.
    Reply

  11. Gnangarra says:

    Just a thought could a QRpedia scan with translation app be a down load option for people, the app could offer preferred language, plus an alternate language, the reader would check out those two language WP for an article; Once a person has the app they can make their own choices, modify language options as they want if neither is available then it offers a google translation from the local language to the persons primary language choice. eg your phone is set to fr, sp you go into a museum in germany(de) case 1 scan a qr code it returns an article off de:wp which is also in en,fr,sp you get fr version case 2 its available in de, en, sp you get the sp version case 3 its available in de only you get a google translation to fr
    Reply

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.

Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <p> <pre> <br> <img src="" alt="" title="" srcset="">