Our users need to submit a form for submitting a request. Form is available in multiple languages. This form has text box ( the most important field, works as a auto suggest search box). We used to have 3 drop down boxes for choosing category, sub-category and last entity. But as list has increased from 25 to few thousands we are thinking of using auto suggest search box. Now the problem we observed for this field (through analytics) is that users having the form in their local language, tend to (consciously or unconsciously) type and search for the expected field in local language as well as sometimes in English. The reason could be users might not know the exact word in English but might know the word in local language and vice a versa. In order to cater to this problem, we are thinking of having flexibility to let them search in English or their local language.

We have few options now:

  1. Auto suggest search box with radio buttons on top for English and their local language. Pros: Clear for searching and results can be anticipated Cons: Needs extra attention for choosing language radio button. I don't think its intuitive enough as it will make use conscious that he needs to type in only one language.)

  2. Auto suggest search box which lets user search in any language, while typing, it will detect language (e.g. Japanese) and based on that it will start showing auto suggest options for that language but will have corresponding words in other language (e.g. English) in bracket as two column view for results.Pros: Intuitive UI, users don't need to make conscious decision whether to search in local language or English, supports unconscious typing Cons: dealing with languages having same characters as English (e.g. Portuguese) System itself will get confused when user starts typing only few characters (e.g. Portuguese), system will not understand whether its English characters or Portuguese. So for those characters, results from both languages will differ.

How can I enhance these options to come up with solution to make user select the expected area of interest with minimum interaction/cognitive load?

Note: We are going to have lookup (hyperlink) functionality where users will be able to browse and locate exact option. But this is fall back option to be used when user fails to get any result through auto search box.

  • Is the rest of the website/app in their local language? If so do they choose this? As if you have chosen a language, it would be odd to see another in a search box. Commented Nov 25, 2014 at 13:04
  • @StephenKeable Yes, rest of the pages are in local language. And inspite of that, they choose to switch in between local and English language. The reason being, (applies to mostly non-English native language people) even we tend to use English words in daily local language. Removing these English words and replacing with purely translated local language words in not user friendly. Because this 'MIX' is their language. and the problem is how do we cater to this situation.
    – Spicerjet
    Commented Nov 26, 2014 at 6:05
  • 1
    that's really interesting. If analytics shows that users search in their native and english typically I guess that's solution that would be required. Although I know multilingual search can be quite a technical challenge possibly. But should hopefully worth the dev time to delight your users. Commented Nov 26, 2014 at 9:57
  • What's wrong with searching for "come" and getting results that use "come" in English and "come" in Italian? users know the difference don't they?
    – Ayyash
    Commented Nov 28, 2014 at 10:33
  • Is there a reason you can't return (filter) based on either language entered. Maybe if they are in English language but typing in French 'baguette' just show the list as 'Bread (Baguette)', or otherwise if they search in the 'correct' language just return either 'Bread' or 'Baguette' singularly. Sounds like the user is using multiple languages, breaking out of the UI constraint you placed on them by having one language only.
    – S..
    Commented Dec 1, 2014 at 20:41

7 Answers 7


For a bilingual search, do not detect the language, just search both and return results from both searches. E.g. when typing "ma" in the autocomplete search box, you could get:

maçã (apple)
ácer (maple)

For multilingual, it wouldn't work that well, but if the search in the chosen language returns 0 hits, you could use a whole-word search in all languages and display good matches from that search...


Currently you hide a huge content from users, but it's a critical point for your service. Using multi-language makes the case even worse. For Google it works, but they have strong back-end for doing this.

I suggest explicit presentation of the content, using multi-level selection. So you build strong information architecture of your content, which has the benefits:

  1. Represent the coverage of your content in explicit way
  2. Streamline the user flow from highest to lowest level with minimal errors
  3. Language-independent solution (less errors)

As this option is space-consuming, you could divide the flow on two steps:

  1. User selects the area of interest
  2. User fills the rest of the fields. If the first step was successfuly passed, they have enough motivation to finish the task
  • 1
    I used to agree with representing coverage of the content, I assumed it to be kind of USP; but later came to know that PM's don't want to promote it so prominently also. It might add unnecessary fear to choose option from 3 dependant drop downs. They will not know which first option to go for (very broad categories), options for second drop down depends on selection of first and so one, so if user chooses wrong category for first one, it will add frustration as even after using 2 more drop downs (+clicks +time) he will not be satisfied with that. And bilingual problem still remains as it is!
    – Spicerjet
    Commented Nov 24, 2014 at 13:51
  • @Spicerjet you don't limited with dropdowns to provide selection flow to lowest level. Building right information architecture isn't easy, but it helps for users to reach a target in a smooth way. You need no count clicks, rather think of users' cognitive load. Conduct comparative usability test to get the better solution. Commented Nov 25, 2014 at 13:07
  • Agree! even if we don't count clicks, cognitive load is frustrating. If users don't know which first category to choose in order to go granular for next 2 drop downs, when they reach third, if they come to know they have made wrong decision as no expected option is visible, they need to follow reverse process or need to restart. How do we solve this apart from drop downs or auto suggest search upfront? we have fall back option (mentioned in Note) but we don't want user to use it as it is overwhelming.
    – Spicerjet
    Commented Nov 26, 2014 at 6:11

Don't ask the user a question if you don't have to.

Same answer essentially as @Aprillion but explicit rendering can help user e.g.


download bmml source – Wireframes created with Balsamiq Mockups

Will work OK with up to 3 languages - so default to English + users locale + (optionally) IP based locale


Enforcing one language on an element within a multilingual experience might be confusing.

If your users are using several languages on the app, then that should be respected. Otherwise it could be mysterious why all of a sudden everything appears in English, for example.

However, to eliminate confusion on the auto-suggest element, you could simply allow the user to limit (filter) results by language. Similar to what google does in the advanced search:

screenshot http://gyroscopestudios.com/stackexchange/searchScreen.png

Let the user choose when to apply the language filter. This will afford them the opportunity to make things easier on themselves without hiding information or functionality leaving them in control.

Getting feedback early is helpful. You should talk to a subset of users about what they think and then monitor usage to see how well they are performing. This might lead you to novel ways to solve this issue going forward.


System itself will get confused when user starts typing only few characters (e.g. Portuguese),

You could delay the search keyword matching until a full word has been entered. That way you can match an appropriate item (in either language).


I think option one is not really an option: making users switch between two languages while they are trying to come up with a good query is not such a good idea.

It's better to present results in both languages at once, as you are suggesting in option two (and as Aprillion and other commenters agreed).

I suggest two adjustments:

  1. not splitting the results in two columns, as it would a bit hard to browse.

  2. showing category, since you are mentioning easy choice of the "expected area of interest".

enter image description here

Longer the query will be, more precisely system will know which word(s) is in question, and probably less results will be presented.


There are good answers, I want to add: trial and error.

Probably you don't know so much your users to arrive a good solution at once. And for sure, we don't know neither your users nor your website. So, you could implement several solutions and made statistics.

  • First, use beta testers.
  • Then, implement changes gradually (for a growing number of users).

Also, I want to add another solution to test:

Trace which words are most used in every language, and if you can group by user native language, user country, etc.

So, maybe your users are writing "apple" and "morango". So when user press "m" put "morango" in top of "maçã". Or maybe your Brazilian users use one word, and your Portuguese users the other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.