Last modified: 2007-01-10 05:41:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5376 - Move all the tooltips to system messages, instead of Monobook.js
Move all the tooltips to system messages, instead of Monobook.js
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.8.x
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 5051
  Show dependency treegraph
 
Reported: 2006-03-28 10:01 UTC by Rotem Liss
Modified: 2007-01-10 05:41 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rotem Liss 2006-03-28 10:01:08 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.
Comment 1 Melancholie 2006-03-28 12:39:58 UTC
See also: Bug 5051
Comment 2 Rob Church 2006-03-28 14:30:02 UTC
(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?
Comment 3 Rotem Liss 2006-03-28 14:57:42 UTC
(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.
Comment 4 Purodha Blissenbach 2006-07-22 06:08:47 UTC
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.
Comment 5 Niklas Laxström 2006-07-30 15:50:58 UTC
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.
Comment 6 Andrew Dunbar 2006-07-30 18:03:43 UTC
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.
Comment 7 Andrew Dunbar 2006-09-01 06:06:09 UTC
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
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-09-03 02:28:41 UTC
(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.
Comment 9 Andrew Dunbar 2006-09-03 10:05:30 UTC
> 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.
Comment 10 Dan Li 2006-09-03 17:10:30 UTC
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?
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-09-03 17:36:21 UTC
(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.

Comment 12 Andrew Dunbar 2006-09-03 22:23:39 UTC
> 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?
Comment 13 Rotem Liss 2006-09-04 16:16:37 UTC
(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.
Comment 14 Rotem Liss 2006-09-04 16:17:17 UTC
(In reply to comment #13)
> The updates don't apply.

If we ever changed Monobook.js, I mean.
Comment 15 Raimond Spekking 2006-10-20 20:20:48 UTC
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.
Comment 16 Rotem Liss 2006-10-22 15:26:44 UTC
(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.
Comment 17 Melancholie 2006-10-25 17:43:43 UTC
(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
Comment 18 Rotem Liss 2006-10-25 17:47:53 UTC
(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.
Comment 19 Melancholie 2006-10-26 15:09:48 UTC
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!
Comment 20 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-26 21:18:08 UTC
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.
Comment 21 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-30 04:34:52 UTC
Fixed in r17297.
Comment 22 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-30 17:27:07 UTC
Incomplete patch rolled back and branched, should be recommitted in a week or less.
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-10 05:41:49 UTC
Fixed again in r19036.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links