Last modified: 2007-01-10 05:41:49 UTC
Why should the tooltips defined in Monobook.js? It should be reserved for scripts defined in the site, and it's better to use the system messages. And by the way, please cancel the "accesskey-" messages (it shouldn't be defined in Messages.php), and automatically include the text "[alt-s]" etc. in every tooltip - don't do that in the system messages. For example, "tooltip-search" should be "Search {{SITENAME}}" instead of "Search {{SITENAME}} [alt-f]", and "accesskey-search" should be canceled and defined in the code itself.
See also: Bug 5051
(In reply to comment #0) > Why should the tooltips defined in Monobook.js? It should be reserved for > scripts defined in the site, and it's better to use the system messages. Because they're set up using JavaScript. > And by the way, please cancel the "accesskey-" messages (it shouldn't be defined > in Messages.php) Why not? > "accesskey-search" should be canceled and defined in the code itself. What happens if someone wants to change or remove access keys without hacking the code?
(In reply to comment #2) > (In reply to comment #0) > > Why should the tooltips defined in Monobook.js? > > Because they're set up using JavaScript. Why should they use JavaScript? Just add "title" attribute with the system message.
I have not looked into the code, but there must be a place, where "[alt-s]" etc. are being defined. If you alter that definition, you would alter the key to be, e.g. "[alt- q]". Imho, this should be the ONLY place to mention the key, all other places, including messages, have to make use of that definition. So the design of current messages is flawed. Also it is outright wrong to have the messaegs added by javascript, so: - some won't see them (accepting javascript over a unsecured http connections is a security risk, btw.) - you are wasting client side ressources - there is a standard-conformat way of doing it. Tooltip messages should each be configuerd like all other messages, then the problem of having duplicated definitions is avoided. MediaWiki:Tooltip_xxx = "Some text possibly using {{MediaWiki:Toolkey_xxx}} will do" Setting MediaWiki:Toolkey_xxx = "" could be used to disable individual keys.
The key combination hint [<combination>-s] can only be added using javascript, so we cant get rid of javascript even if we used system messages. And um, connecting to Internet is a security risk, btw.
The browser identifies itself to the server so the combination hint can just as easily be handled by PHP as by JavaScript. Remember that now people without JavaScript get no combination hints at all.
I'm upping the severity to major because the side effect of using MediaWiki:Monobook.js for internationized strings, and having no other place for language-independant JavaScript is that all code must be copied to each and every language file (MediaWiki:Monobook.js/es, MediaWiki:Monobook.js/de, etc). The English Wiktionary is currently broken for example because the cookie functions exists in MediaWiki:Monobook.js and are called by Edittools but of course do not exist in any of the language variants of Monobook.js
(In reply to comment #6) > The browser identifies itself to the server so the combination hint can just as > easily be handled by PHP as by JavaScript. I can't speak with certainty on this, but anything that sends different pages to different people hurts caching, at least potentially. Possibly this is even INVALID. (In reply to comment #7) > I'm upping the severity to major because the side effect of using > MediaWiki:Monobook.js for internationized strings, and having no other place for > language-independant JavaScript is that all code must be copied to each and > every language file (MediaWiki:Monobook.js/es, MediaWiki:Monobook.js/de, etc). > > The English Wiktionary is currently broken for example because the cookie > functions exists in MediaWiki:Monobook.js and are called by Edittools but of > course do not exist in any of the language variants of Monobook.js The solution there is to write language variants to call common functions with language-specific aspects passed as arguments, or write the common functions to call language-specific functions that will return a desired string. Basically just move all the messages out of the code itself, the way MediaWiki proper is set up. Moving it from JavaScript to PHP isn't the only option from that particular perspective. As much as possible should be moved to PHP, but client-specific stuff might not be movable there. This is not unintended behavior, even if it may be flawed, and therefore is not a bug. Severity is enhancement.
> The solution there is to write language variants to > call common functions with language-specific aspects > passed as arguments, or write the common functions to > call language-specific functions that will return a > desired string. Basically just move all the messages > out of the code itself, the way MediaWiki proper is > set up. Moving it from JavaScript to PHP isn't the > only option from that particular perspective. As much > as possible should be moved to PHP, but client- > specific stuff might not be movable there. The problem is there is no place to put common functions other than MediaWiki:Monobook.js - if there were a MediaWiki:Common.js which was not locale-specific or if both MediaWiki:Monobook.js and MediaWiki:Monobook.js/en existed then the tooltip code can go in the latter and functions without hard-coded strings in the former.
MediaWiki:Monobook.js is not directly included by users; it is part of the generated javascript for users. Couldn't the tooltip javascript be dynamically generated with all the correctly localized tooltip system messages? As for caching, the generated javascript is cached client-side for logged-in users, and cached both client-side and server-side (I think) for anons. Is that what the argument here is about? Thanks. P.S.: Version is 1.8-svn, right?
(In reply to comment #9) > The problem is there is no place to put common functions > other than MediaWiki:Monobook.js - if there were a > MediaWiki:Common.js which was not locale-specific or if > both MediaWiki:Monobook.js and MediaWiki:Monobook.js/en > existed then the tooltip code can go in the latter and > functions without hard-coded strings in the former. So put the functions there and use document.write to include whatever language-specific stuff you need.
> So put the functions there and use document.write to include > whatever language-specific stuff you need. document.write is a hack and it still requires putting document write in each and every language version of Monobook.js/xx Why such hostility to a real fix? Why not split out MediaWiki:Tooltips.js(/xx) and include it the way other skin files are? The generated JavaScript can still consist of both Monobook.js and Tooltips.js Also, what happens when the localisation files are updated? Do we currently risk losing our code from Monobook.js or are such updates simply not applied to modified files thus leaving strings to go stale?
(In reply to comment #12) > Also, what happens when the localisation files are updated? Do we > currently risk losing our code from Monobook.js or are such updates > simply not applied to modified files thus leaving strings to go > stale? The updates don't apply.
(In reply to comment #13) > The updates don't apply. If we ever changed Monobook.js, I mean.
We need a reworking of the tooltip system less or more urgently. All tooltips defined as [[MediaWiki:tooltip-xxx]] shows the <combination> as "alt-" hardcoded by the message. This results in inconsistent tooltips at browsers using other <combinations> then "alt". The coming Firefox 2 has changed its accesskey <combination> to "shift-alt" so we will get a lot of complains/bugs in the near future I suppose.
(In reply to comment #15) > We need a reworking of the tooltip system less or more urgently. All tooltips > defined as [[MediaWiki:tooltip-xxx]] shows the <combination> as "alt-" hardcoded > by the message. This results in inconsistent tooltips at browsers using other > <combinations> then "alt". > > The coming Firefox 2 has changed its accesskey <combination> to "shift-alt" so > we will get a lot of complains/bugs in the near future I suppose. Right, though it's another bug. The "tooltip-x" messages should be somehow renamed (to invalidate the messages from MediaWiki: namespace) and the "[alt-x]" part should be removed from them.
(In reply to comment #15) > We need a reworking of the tooltip system less or more urgently. All tooltips > defined as [[MediaWiki:tooltip-xxx]] shows the <combination> as "alt-" hardcoded > by the message. This results in inconsistent tooltips at browsers using other > <combinations> then "alt". > > The coming Firefox 2 has changed its accesskey <combination> to "shift-alt" so > we will get a lot of complains/bugs in the near future I suppose. 1. Not all browsers show the <combination> as "alt-", as the whole thing is done by JavaScript and by browser sniffing; see http://en.wikipedia.org/skins-1.5/common/wikibits.js (function akeytt) 2. See my #1. Furthermore, Simetrical has added some lines for FF2: else if (is_ff2) pref = 'shift-alt-'; See also: r1=17118&r2=17136">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?r1=17118&r2=17136 and Bug 7636
(In reply to comment #17) > 1. Not all browsers show the <combination> as "alt-", as the whole thing is done > by JavaScript and by browser sniffing; see > http://en.wikipedia.org/skins-1.5/common/wikibits.js (function akeytt) > > 2. See my #1. Furthermore, Simetrical has added some lines for FF2: > else if (is_ff2) > pref = 'shift-alt-'; > See also: > r1=17118&r2=17136">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?r1=17118&r2=17136 > and Bug 7636 As far as I understand, the comment means the MediaWiki:Tooltip-xxx messages, not the tooltips defined in MediaWiki:Monobook.js. You described the behavior of the messages defined in MediaWiki:Monobook.js, but they *are* hard-coded in MediaWiki:Tooltip-xxx.
Please have a look at [[Talk:Mozilla_Firefox#Altered_hotkey_behaviours_for_Wikipedia]]. If that is true, now you also have to provide "Alt+Shift+key" under Windows, "Ctrl+key" under Mac OS X, and "Ctrl+Shift+key" under *nix!
Not entirely incorrect (IE is still Alt-key for now), but irrelevant to this bug except to demonstrate that we cannot, in fact, move the tooltips to system messages, at least not entirely.
Fixed in r17297.
Incomplete patch rolled back and branched, should be recommitted in a week or less.
Fixed again in r19036.
