There is a sort-of rule of thumb that about 85% of defects will show up if you test all pairs of the factors. You can almost certainly test all pairs in your c

There is a sort-of rule of thumb that about 85% of defects will show up if you test all pairs of the factors. You can almost certainly test all pairs in your case if you test all combinations of browsers with devices (20 cases) and assign the languages so that each language is tested at least once on each browser and each device. Check out the math for 'orthogonal arrays' if you want to see what is known about how to cover all pairs of factors with a minimum number of test cases. If you have four or more dimensions in your space of test cases and want to cover all combinations of three factors, see 'orthogonal arrays of strength 3.' Unfortunately, 85% is less than 100%. And testing correctness of the system in your case probably requires a set of human eyes looking at the screen, and it may also require testing all kinds of scenarios of changing the window size, and user pressing the tab keys, etc, to make sure that there is no browser logic conflicting with your display logic, etc, is probably a good idea, too. For applications critical for health, safety, gigabucks or survival of the planet, 85% allows a little too much room for catastrophe, and the common solution is bondage and discipline -- vendor supplied hardware with all software and config pre-installed, user hardware configuration protected from user caprice, etc. For ordinary internet applications in the workaday world, damn-the-torpedoes is the typical workaday response. For example, I am one of the users who is a little more likely to experience the occasional lack of full functionality in UI settings -- I have eyes that don't like tiny fonts, so I set my font size considerably larger than average and my screen resolution smaller (that buying a screen with high resolution makes things harder to read always annoys me). Plenty of apps and pages on the internet fail for me. Either the user (1 person at a time) or the development org (large team?) has to get along by going along. Your case may be one of the regrettable situations in which 'going along' means fixing the rare problem that you miss that also actually impacts an actual user, but there may be some pretty high likelihood that the fix for the rare case is likelihood to cause other breakages. Good luck.