Last modified: 2013-09-02 11:18:12 UTC
currrent 'control+m' toggel option is available but is usefull in between selected language keyboard and pc-native keyboard, one more toggle option for bilingual usage like say japanese and sanskrit, this option would be benefitting for wiktionaries. Thanks and Warm Regards
[Please set severity "enhancement" for feature requests. Thanks!] (In reply to comment #0) > currrent 'control+m' toggel option is available but is usefull in between > selected language keyboard and pc-native keyboard, one more toggle option for > bilingual usage like say japanese and sanskrit, this option would be > benefitting for wiktionaries. I don't understand. Could you elaborate what is missing and why current functionality does not work for you? :(
The current functionality is working what I am asking for is an additional feature. Say presently I am usually using अक्षरांतरण (transliteration) method in available input methods for marathi language In current functionality control+m allows me to toggle only with my native pc-keyboard (Which is english).So this functionality is any way needed. But when I will be working on wiktionary I know language Hindi also. While ULS provides me with facilty to use Hindi transliteration input method लिप्यंतरण but for that also with control+m I can togggle in between Hindi and native pc keyboard which is english.If I am a bilingual usually at wiktionaries and at time of translations I need to toggle directly in between two languages say for in my case I want to toggel directly between Marathi अक्षरांतरण and Hindi लिप्यंतरण The additional feature will also be usefull while writing language learning articles on wikibooks Thanks and regards
The feature request is clear to me. In my opinion, this is outside of the scope of what we want to provide with ULS. If switching between one keyboard layout and the native keyboard layout is wanted, I consider this already an expert use case, and I would suggest finding specialised software (or operating system supported features) to make fulfilling the need possible. Adding this to ULS would increase the complexity of the solution, most likely increasing difficulty of the basic use cases, or allowing more room for confusion because of the increases number of use cases. I also do not see value in adding this feature for a large group of potential users. I'm assigning "lowest" priority to this feature request. I think there is a high chance of this issue being closed as "won't fix" in the future because of the above.
The feature request is clear to me. In my opinion, this is outside of the scope of what we want to provide with ULS. If switching between more than one keyboard layout and the native keyboard layout is wanted, I consider this already an expert use case, and I would suggest finding specialised software (or operating system supported features) to make fulfilling the need possible. Adding this to ULS would increase the complexity of the solution, most likely increasing difficulty of the basic use cases, or allowing more room for confusion because of the increases number of use cases. I also do not see value in adding this feature for a large group of potential users. I'm assigning "lowest" priority to this feature request. I think there is a high probability of this issue being closed as "won't fix" in the future because of the above.
(Removing private flag from comment 3 as there's no good reason to hide it from others, except for being a duplicated comment by mistake.)
>>increasing difficulty of the basic use cases(In reply to comment #3) > The feature request is clear to me. In my opinion, this is outside of the > scope > of what we want to provide with ULS. If switching between one keyboard layout > and the native keyboard layout is wanted, I consider this already an expert > use > case, and I would suggest finding specialised software (or operating system > supported features) to make fulfilling the need possible. > > Adding this to ULS would increase the complexity of the solution, most likely > increasing difficulty of the basic use cases, or allowing more room for > confusion because of the increases number of use cases. I also do not see > value > in adding this feature for a large group of potential users. > > I'm assigning "lowest" priority to this feature request. I think there is a > high chance of this issue being closed as "won't fix" in the future because > of > the above. >>increasing difficulty of the basic use cases<< ::I also do not want this solution at the cost of increasing difficulty of the basic use cases ; So frankly I prefer to withdraw the request and would welcome to put to wontfix so rest expert level people do not put pressure on ULS developer team. Thanks and Regards
*** Bug 53028 has been marked as a duplicate of this bug. ***
