Wiki.Melancholie wrote:

See also: Bug 5051

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?

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.

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

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.

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.

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?

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.

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?

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.

rotemliss wrote:

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

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.

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)

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

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.

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!

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.

ayg wrote:

Fixed in r17297.

ayg wrote:

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

ayg wrote:

Fixed again in r19036.