For the text direction use case, the input locale is highly likely to correspond to the actual text being written. For example, when the Hebrew keyboard is in use, it is only possible to type uppercase Latin-script letters, so in the vast majority of cases the user switches to the English keyboard for English text. For the smart-quotes use case, it is important to note that the whole feature is a heuristic, and complete correctness is not required. An application using this approach should really allow the user to specify the document language explicitly (as well as turn smart quotes off completely). Nevertheless, when the user does not specify the language - and one would have to presume that this will be case most of the time - the input locale is a higher-quality signal than the other possibilities: the system user interface language, the browser user interface language, and the language setting for the HTTP request. (Not that the browsers actually expose all of these.) For monolingual (and 1.5-lingual, i.e. write in only one language) users, all of these signals as well as the input locale are highly likely to have the same value. For bilingual users, however, the keyboard locale has a good chance of being changed when the user starts writing in a different language, while the other signals most certainly don't. It is worthwhile adding that Microsoft Word, the most widespread word processor, uses keyboard language for both of the use cases given. AharonReceived on Sunday, 12 September 2010 14:58:42 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:40:58 UTC