Last modified: 2013-06-26 09:53:41 UTC
It is off per default for Italian. So do it for German. I (German) see the link on top of each page. and the checkmark in my prefs (https://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-editing) is not set. the pref is titled "Narayam-Editor deaktivieren" - so it is active if the checkmark is not set. "German [de]: umlauts and sz" is the "input method" which is provided. No one needs this. It is already available via the toolbar if someone isn't able to type it and needs it. Useless resource trashing. Do not do it! Thanks.
Note: This is a regression introduced by [[bugzilla:32997]].
correction: it's on for Italian as well, but there's no input method
(In reply to comment #1) > Note: This is a regression introduced by [[bugzilla:32997]]. ? Bug 32619 perhaps? So, I've tried to rephrase this request: perhaps it makes sense to define languages (with an existing input method) for which the menu is somehow disabled by default or hidden, is someone comes up with an idea to do it.
(In reply to comment #3) > (In reply to comment #1) > > Note: This is a regression introduced by [[bugzilla:32997]]. > > ? Bug 32619 perhaps? Well - yes. ;-) > So, I've tried to rephrase this request: perhaps it makes sense to define > languages (with an existing input method) for which the menu is somehow > disabled by default or hidden, is someone comes up with an idea to do it. It makes sense simply not to load the script per default for languages which do not need it. For languages for which this ''may'' be useful the checkbox in the renamed option ("Enable Nayaram") in the preferences can be checked by default.
(In reply to comment #4) > the renamed option ("Enable Nayaram") in the preferences can be checked by > default. that is [[bugzilla:31917]], btw
(In reply to comment #2) > correction: it's on for Italian as well, but there's no input method Please define "it is on". What does that mean? (In reply to comment #4) > It makes sense simply not to load the script per default for languages which do > not need it. For languages for which this ''may'' be useful the checkbox in > the renamed option ("Enable Nayaram") in the preferences can be checked by > default. That is not necessarily true. If you only have a US English keyboard and you cannot control your computer's input methods, it is pretty handy to be able to choose an input method for German (or Polish, Hungarian, or whatever language you think "does not need it"). You not needing it in your current situation is not equal to not being needed. Can we agree on that? As far as I can tell, this issue has little substance so far, please please provide it, or we should close it as invalid.
(In reply to comment #6) > Please define "it is on". What does that mean? Hell yeah.. "on" = script loads and link displays on top of each page left of my username (when I am logged in). > That is not necessarily true. If you only have a US English keyboard and you > cannot control your computer's input methods, it is pretty handy to be able to > choose an input method for German (or Polish, Hungarian, or whatever language > you think "does not need it"). You not needing it in your current situation is > not equal to not being needed. Can we agree on that? It is not needed for 99% of the users. And not really needed for 99.5% since they know either the toolbar with the special characters or they are clever enough to properly use their OS. > As far as I can tell, this issue has little substance so far, please please > provide it, or we should close it as invalid. Pardon? Are you trying to fool me?
(In reply to comment #7) > It is not needed for 99% of the users. And not really needed for 99.5% since > they know either the toolbar with the special characters or they are clever > enough to properly use their OS. Apparently, the 99% of the users logic doesnt hold water. I have tried it convincing siebrand citing same for webfonts and have failed. I also think he has a point to enable it and be inclusive to those 1%. In case of Narayam, since its fairly stable doesnt cause any harm to 99%(though you might not want it), i dont think its an issue. What is required is the documentation link which can tell you(and other 99% folks who dont need it) how to disable it (not many would have noticed in editing prefs), so if one feels useless resource trashing, they can feel free to disable it. That would be done in fortnight i believe
Well, you are clever guys. GeoIPLookup provides the city and country from where the person is editing from. E.g. people editing from Germany with German-language-settings do not need it because it is sooooo unlikely that the have an English keyboard. And as pointed out by Saibo users having an English-layout will be professional knowing how to fix it him-/ herself or how to activate the extension. If I am activating something on Commons with fewer impacts, I have a long, long discussion before I can proceed. But the techs always do something even without notifying the community. THIS IS NOT OK. Why can’t you at least run a watch list-note, drop a line next to the village pump or ask someone to do so. Das ist wie mit den Krankenkassenrabattverträgen. Die Patienten wundern sich immer wieder, warum sie ein neues Medikament untergejubelt bekommen. Manche sind sogar böse. Nur Kommunikation kann das Problem lösen. Und die Server-Admin-Logs sind es sicher nicht. Unfortunately it changes my mouse-pointer into a hand-symbol in text-fields. That is really uncommon and not convenient when you try to select text. Ok, that's no big deal, I think. In general, I like improving accessibility. This is important. What we really need is something that let us control the manner we're activating extensions and gadgets. (Country, language, usergroup, ...) For the nasty banners you already have such a system.
Adding design keyword so that designers can suggest a way an interface to do what requested, if possible. (In reply to comment #9) > Unfortunately it changes my mouse-pointer into a hand-symbol in text-fields. > That is really uncommon and not convenient when you try to select text. Ok, > that's no big deal, I think. Sounds like a separate enhancement request. > [...] What we really need is something that let us control the manner we're > activating extensions and gadgets. (Country, language, usergroup, ...) [...] I don't think so and this is certainly not the place where to discuss it. Open a discussion on wikitech-l to explain this concept and listen to replies.
It is still enabled per default on Commons.
Not going to fix this -- IME UI is currently visible if there is an IME for the user language. There are two options now: disable Input methods in your preferences to no longer show them, or live with the current implementation. As said: the UI will be redesigned, after which the IME selector will be stuffed away in a more appropriate place.
reopened. Still the described bug.
There isn't any bug, but it was made clear that the feature request is not going to be accepted, while the problem will be considered in the redesign. Hence reclosing.
(In reply to comment #14) > There isn't any bug, but it was made clear that the feature request is not > going to be accepted, while the problem will be considered in the redesign. > Hence reclosing. It is useless for German (and probably other languages) but still shows up (taken aside the uncessary code load). How on earth is this not a bug? It even shows up for non-registered users who cannot switch it of (even if they would find it in their prefs)...
(In reply to comment #15) > It is useless for German (and probably other languages) but still shows up > (taken aside the uncessary code load). How on earth is this not a bug? It even > shows up for non-registered users who cannot switch it of (even if they would > find it in their prefs)... It is indeed a bug, but just that since a design change is happening, fixing these bugs would be redundant and the inputs would be taken in the newer UI design. So this bug WONTFIX for now, but will eventually get fixed in the new UI. //This probably is a valid bug to mark RESOLVED LATER, but then there is a decision not to use LATER, so marking WONT FIX
