Nice to have all the world's alphabets at one's fingertips right there on the (www.mediawiki.org) edit page. Wow, IPA, Pīnyīn, they're all there. I'm saving it for even when I'm not editing MediaWiki.
(However, as it bloats the edit page up to 700% $ wget -O x.html http://www.mediawiki.org/w/index.php?title=WHATEVER%5C&action=edit $ perl -nwle 'print unless /onclick/' x.html|wc -c - x.html|sed '$d' 19748 - 139708 x.html there should also be some mechanism available for pages like these for users to opt out, perhaps via Preferences?)
On Mon, Mar 23, 2009 at 8:10 AM, jidanni@jidanni.org wrote:
Nice to have all the world's alphabets at one's fingertips right there on the (www.mediawiki.org) edit page. Wow, IPA, Pīnyīn, they're all there. I'm saving it for even when I'm not editing MediaWiki.
(However, as it bloats the edit page up to 700% $ wget -O x.html http://www.mediawiki.org/w/index.php?title=WHATEVER%5C&action=edit $ perl -nwle 'print unless /onclick/' x.html|wc -c - x.html|sed '$d' 19748 - 139708 x.html there should also be some mechanism available for pages like these for users to opt out, perhaps via Preferences?)
Yeah, CharInsert is a mess:
<a onclick="insertTags('–','','');return false" href="#">–</a> <a onclick="insertTags('—','','');return false" href="#">—</a> · <a onclick="insertTags('“','”','');return false" href="#">“”</a>
Why can't the HTML for this be something like
<span class="insert">–</span> <span class="insert">—</span> · <span class="insert">“”</span>
Or even just
<span>–</span> <span>—</span> · <span>“”</span>
with JavaScript parsing it to make the characters clickable?
Aryeh Gregor schreef:
with JavaScript parsing it to make the characters clickable?
Since all of this requires JavaScript to work anyway, a quick and dirty first step to un-bloating stuff would be to move all of the charinsert stuff to a separate .js file whose sole purpose is to add the charinsert/edittools stuff to the edit form. That'll at least spare non-JS users, and should make disabling easier.
Roan Kattouw (Catrope)
On 3/23/09 9:17 AM, Roan Kattouw wrote:
Aryeh Gregor schreef:
with JavaScript parsing it to make the characters clickable?
Since all of this requires JavaScript to work anyway, a quick and dirty first step to un-bloating stuff would be to move all of the charinsert stuff to a separate .js file whose sole purpose is to add the charinsert/edittools stuff to the edit form. That'll at least spare non-JS users, and should make disabling easier.
This has been discussed a few times over the years; I think it's been sort of custom-hacked up to work kind of like that on en.wikipedia.org. :)
A clean implementation would be nice, any volunteers?
-- brion
Hello,
2009/3/23 Brion Vibber brion@wikimedia.org:
On 3/23/09 9:17 AM, Roan Kattouw wrote:
Since all of this requires JavaScript to work anyway, a quick and dirty first step to un-bloating stuff would be to move all of the charinsert stuff to a separate .js file whose sole purpose is to add the charinsert/edittools stuff to the edit form. That'll at least spare non-JS users, and should make disabling easier.
This has been discussed a few times over the years; I think it's been sort of custom-hacked up to work kind of like that on en.wikipedia.org. :)
A clean implementation would be nice, any volunteers?
I volunteer to work on this. Is there any special way for doing JavaScript so it functions on WMF sites, or is /scriptpath/extensions/foo/bar.js acceptable?
Regards, Robert Leverington (MinuteElectron)
On 3/24/09 3:50 AM, MinuteElectron wrote:
2009/3/23 Brion Vibberbrion@wikimedia.org:
On 3/23/09 9:17 AM, Roan Kattouw wrote:
Since all of this requires JavaScript to work anyway, a quick and dirty first step to un-bloating stuff would be to move all of the charinsert stuff to a separate .js file whose sole purpose is to add the charinsert/edittools stuff to the edit form.
This has been discussed a few times over the years; I think it's been sort of custom-hacked up to work kind of like that on en.wikipedia.org. :)
A clean implementation would be nice, any volunteers?
I volunteer to work on this.
Awesome! :D
Is there any special way for doing JavaScript so it functions on WMF sites, or is /scriptpath/extensions/foo/bar.js acceptable?
For extensions that's pretty much how we do it. :)
-- brion
Seems reasonable for logged in users to opt in for languages they are going to actually use, but what about anonnomous users? Perhaps it could be a hidden field with an Ajax(/some fallback) control that only loads the other languages when the user asks for them, which would probably be seldom. Finally, we could we ask them if they want to use that language as thier default from now on with a little checkbox, reducing annoyance and also number of requests for the whole list by keeping state information.
These features would also be useful for commons afaik.
- Trevor
Sent from my iPod
On Mar 23, 2009, at 5:10 AM, jidanni@jidanni.org wrote:
Nice to have all the world's alphabets at one's fingertips right there on the (www.mediawiki.org) edit page. Wow, IPA, Pīnyīn, they're all there. I'm saving it for even when I'm not editing MediaWiki.
(However, as it bloats the edit page up to 700% $ wget -O x.html http://www.mediawiki.org/w/index.php?title=WHATEVER%5C&action=edit $ perl -nwle 'print unless /onclick/' x.html|wc -c - x.html|sed '$d' 19748 - 139708 x.html there should also be some mechanism available for pages like these for users to opt out, perhaps via Preferences?)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello,
We have been looking in to making a few modifications to edit tools to make it more useful, and spent some time discussing various solutions. At the moment we have a specification for some basic additional features [1] (waiting for auditing) but as it stands this does not solve all of the problems - and a more involved solution will be necessary to satisfy other requirements.
The first main solution to the problems outlined here would be to have an option in preferences to completely enable or disable the edit tools dialog. This shouldn't be difficult to implement, but lacks any fine grained control over what is displayed - if some of the edittools features are wanted, but not others. Control over the list of groups displayed would require significant changes to the charinsert extension, and is overkill in my opinion. A "memory" of the last selected box would be possible using JavaScript cookies however, avoiding the need to add any additional preferences.
To remove bloat from the page, as pointed out already, a lot of the stuff could be moved to within JavaScript (for example, many of the charinsert calls). I would shy away from any on the fly loading though, such as AJAX, as this adds significant additional overhead which is unnecessary.
It should also be noted that the edittools is usual ordered using script (e.g. Latin, Arabic) rather than language - so using language setting to control this would be unwise.
Regards, Robert Leverington (MinuteElectron)
On 3/23/09 12:57 PM, MinuteElectron wrote:
The first main solution to the problems outlined here would be to have an option in preferences to completely enable or disable the edit tools dialog.
There's really no need for that; an initial load with a sensible architecture would be trivial in terms of HTML weight.
-- brion
wikitech-l@lists.wikimedia.org