Move all the tooltips to system messages, instead of Monobook.js
Closed, ResolvedPublic

Description

Author: rotemliss

Description:
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.


Version: 1.8.x
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz5376.
bzimport created this task.Via LegacyMar 28 2006, 10:01 AM
bzimport added a comment.Via ConduitMar 28 2006, 12:39 PM

Wiki.Melancholie wrote:

See also: Bug 5051

bzimport added a comment.Via ConduitMar 28 2006, 2:30 PM

robchur wrote:

(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?

bzimport added a comment.Via ConduitMar 28 2006, 2:57 PM

rotemliss wrote:

(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.

bzimport added a comment.Via ConduitJul 22 2006, 6:08 AM

bugzilla.wikimedia wrote:

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.

Nikerabbit added a comment.Via ConduitJul 30 2006, 3:50 PM

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.

Hippietrail added a comment.Via ConduitJul 30 2006, 6:03 PM

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.

Hippietrail added a comment.Via ConduitSep 1 2006, 6:06 AM

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

bzimport added a comment.Via ConduitSep 3 2006, 2:28 AM

ayg wrote:

(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.

Hippietrail added a comment.Via ConduitSep 3 2006, 10:05 AM

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.

bzimport added a comment.Via ConduitSep 3 2006, 5:10 PM

dto wrote:

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?

bzimport added a comment.Via ConduitSep 3 2006, 5:36 PM

ayg wrote:

(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.

Hippietrail added a comment.Via ConduitSep 3 2006, 10:23 PM

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?

bzimport added a comment.Via ConduitSep 4 2006, 4:16 PM

rotemliss wrote:

(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.

bzimport added a comment.Via ConduitSep 4 2006, 4:17 PM

rotemliss wrote:

(In reply to comment #13)

The updates don't apply.

If we ever changed Monobook.js, I mean.

Raymond added a comment.Via ConduitOct 20 2006, 8:20 PM

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.

bzimport added a comment.Via ConduitOct 22 2006, 3:26 PM

rotemliss wrote:

(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.

bzimport added a comment.Via ConduitOct 25 2006, 5:43 PM

Wiki.Melancholie wrote:

(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)

  1. See my #1. Furthermore, Simetrical has added some lines for FF2: else if (is_ff2) pref = 'shift-alt-';

See also:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?r1=17118&r2=17136
and Bug 7636

bzimport added a comment.Via ConduitOct 25 2006, 5:47 PM

rotemliss wrote:

(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:

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.

bzimport added a comment.Via ConduitOct 26 2006, 3:09 PM

Wiki.Melancholie wrote:

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!

bzimport added a comment.Via ConduitOct 26 2006, 9:18 PM

ayg wrote:

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.

bzimport added a comment.Via ConduitOct 30 2006, 4:34 AM

ayg wrote:

Fixed in r17297.

bzimport added a comment.Via ConduitOct 30 2006, 5:27 PM

ayg wrote:

Incomplete patch rolled back and branched, should be recommitted in a week or less.

bzimport added a comment.Via ConduitJan 10 2007, 5:41 AM

ayg wrote:

Fixed again in r19036.

Add Comment