Hi!
I've read on the techblog that the new UI go live in April. I have some questions:
1) What version? Acai, babaco, citron? 2) How/where could a wiki customize the special character insert menu, and the inserted strings? And the embed file (picture) button inserts this: "[[Example.jpg]]", without any "File:" or "Image:"! 3) The search and replace button is available in firefox, but does not appear at all in opera. Why? 4) Currently the new navigable TOC does not work on FF/Opera at all (I've tried those).
Not too early for live deployment?
Regards, Akos Szabo (Glanthor Reviol)
2010/3/26 Glanthor glanthor@gmail.com:
Hi!
I've read on the techblog that the new UI go live in April. I have some questions:
- What version? Acai, babaco, citron?
Babaco, mostly. The features being made default are the Vector skin and the enhanced toolbar (including the new dialogs).
- How/where could a wiki customize the special character insert menu,
and the inserted strings?
The entire toolbar can be customized using site JS. There are examples at http://usability.wikimedia.org/wiki/Toolbar_customization ; these currently don't mention how to add/modify special characters entries, I'll add examples for that as well.
And the embed file (picture) button inserts this: "[[Example.jpg]]", without any "File:" or "Image:"!
That's a bug, thanks for reporting it.
- The search and replace button is available in firefox, but does not
appear at all in opera. Why?
Because Opera is broken is subtle ways that make it very difficult to get S&R to work right. We could either enable a broken version of S&R in Opera and be yelled at because it corrupts wikitext (very bad) or disable the feature in Opera (less bad). In the future, S&R should work in Opera as well.
- Currently the new navigable TOC does not work on FF/Opera at all
(I've tried those).
That's deliberate, the TOC requires the iframe, which was disabled because of copy-paste issues. We're also not enabling NTOC as a default feature, so this is irrelevant.
Not too early for live deployment?
Your list consists of a trivial bug (missing File: prefix), a feature (protecting Opera users from text corruption) and the disabling of an unrelated feature that's not slated to go live in April, so I wouldn't say it's too early.
Roan Kattouw (Catrope)
On Fri, Mar 26, 2010 at 16:30, Roan Kattouw roan.kattouw@gmail.com wrote:
and the inserted strings? 2) How/where could a wiki customize the special character insert menu,
The entire toolbar can be customized using site JS. There are examples at http://usability.wikimedia.org/wiki/Toolbar_customization ; these currently don't mention how to add/modify special characters entries, I'll add examples for that as well.
Whatever they mention, i couldn't understand a word of it, and i do know some HTML and JS.
There are several buttons which are essential to me and which disappeared from the new default toolbar, such as nowiki, strikeout and some others. If i had a convenient way to add them, i wouldn't complain, but that [[Toolbar customization]] page is completely unreadable to anyone but the dedicated developers.
And the embed file (picture) button inserts
this: "[[Example.jpg]]", without any "File:" or "Image:"!
That's a bug, thanks for reporting it.
I reported this bug some time ago via "beta feedback". It seems completely trivial, but it's still not fixed. I rarely insert images, so i can live with it, but many other editors do and i have no idea how they live with it.
Not too early for live deployment?
Your list consists of a trivial bug (missing File: prefix), a feature (protecting Opera users from text corruption) and the disabling of an unrelated feature that's not slated to go live in April, so I wouldn't say it's too early.
I'm sorry, but it is too early to force this on editors. On the technical Village Pump in the Hebrew Wikipedia, for example, the attitude towards the beta ranges from indifferent to negative, and not because of RTL problems, but simply because for people who only read Wikipedia this is inessential and for editors it is rather harmful.
True, some people may have enabled the beta and stuck to it, but what about all those that didn't enable it at all or enabled it and returned to Monobook? Do you have any numbers about people who use the beta and actually edit Wikipedia and not just read it?
You should ask for more feedback from the community via sitenotice or watchlist notice before enabling it for everyone.
On 03/26/2010 01:59 PM, Amir E. Aharoni wrote:
On Fri, Mar 26, 2010 at 16:30, Roan Kattouw roan.kattouw@gmail.com wrote:
and the inserted strings? 2) How/where could a wiki customize the special character insert menu,
The entire toolbar can be customized using site JS. There are examples at http://usability.wikimedia.org/wiki/Toolbar_customization ; these currently don't mention how to add/modify special characters entries, I'll add examples for that as well.
I would greatly appreciate some documentation on customising the symbols stuff, copying the symbols part of the given example didn't seem to do anything, but maybe that's because it loaded too late - how would I tell? Also, is it possible to re-order the sets of languages, or to divide the contents of the sets into groups? And will current CharInsert edittools still be available?
Conrad
2010/3/26 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
Whatever they mention, i couldn't understand a word of it, and i do know some HTML and JS.
There are several buttons which are essential to me and which disappeared from the new default toolbar, such as nowiki, strikeout and some others. If i had a convenient way to add them, i wouldn't complain, but that [[Toolbar customization]] page is completely unreadable to anyone but the dedicated developers.
This is a page that was quickly whipped up some time ago, and I agree that it's probably not very readable. I will add a section with some easy instant-copy-and-paste snippets that add stuff like nowiki, strikeout and redirect. If you could elaborate on what "and others" consists of, I'll add those too.
And the embed file (picture) button inserts
this: "[[Example.jpg]]", without any "File:" or "Image:"!
That's a bug, thanks for reporting it.
I reported this bug some time ago via "beta feedback". It seems completely trivial, but it's still not fixed. I rarely insert images, so i can live with it, but many other editors do and i have no idea how they live with it.
I've filed this as https://bugzilla.wikimedia.org/show_bug.cgi?id=22964
I'm sorry, but it is too early to force this on editors. On the technical Village Pump in the Hebrew Wikipedia, for example, the attitude towards the beta ranges from indifferent to negative, and not because of RTL problems, but simply because for people who only read Wikipedia this is inessential and for editors it is rather harmful.
Exactly how is this harmful? The only two problems you listed are a few missing toolbar buttons, which are easily added, and one buggy toolbar button which, by your own admission, you "can live with" (but which we'll of course fix ASAP).
True, some people may have enabled the beta and stuck to it, but what about all those that didn't enable it at all or enabled it and returned to Monobook?
We record both opt-ins and opt-outs. The retention rate (% of users who opted into the Beta and kept it) has been hovering around 80% cluster-wide, with certain specific wikis (such as Japanese and Polish, off the top of my head) showing lower numbers due to specific issues (font size and broken Gadgets, respectively); still "lower" in this case means something like 65-70%.
Do you have any numbers about people who use the beta and actually edit Wikipedia and not just read it?
We don't currently have these numbers, but I suppose we could whip up some statistics about the spread of edit count (more useful metric than "did this user ever edit") among beta users and former beta users that opted back out.
For what it's worth, we'll also be adding a "Take me back" link, similar to the "Try Beta" link, which changes the user's preferences to disable all usability features and change their skin back to Monobook.
Roan Kattouw (Catrope)
On Fri, Mar 26, 2010 at 19:21, Roan Kattouw roan.kattouw@gmail.com wrote:
2010/3/26 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
Whatever they mention, i couldn't understand a word of it, and i do know some HTML and JS.
There are several buttons which are essential to me and which disappeared from the new default toolbar, such as nowiki, strikeout and some others.
If
i had a convenient way to add them, i wouldn't complain, but that
[[Toolbar
customization]] page is completely unreadable to anyone but the dedicated developers.
This is a page that was quickly whipped up some time ago, and I agree that it's probably not very readable. I will add a section with some easy instant-copy-and-paste snippets that add stuff like nowiki, strikeout and redirect. If you could elaborate on what "and others" consists of, I'll add those too.
Thanks.
Note, however, that if you add JS snippets, it may make it usable to me, but probably not quite usable to many people who don't want to learn to edit their vector.js. I've been editing Wikipedia for 5 years and i only created a personal JS file a few days ago.
Making a GUI for adding buttons, at least through the "Gadgets" tab in the preferences, is essential.
I'm sorry, but it is too early to force this on editors. On the technical Village Pump in the Hebrew Wikipedia, for example, the attitude towards
the
beta ranges from indifferent to negative, and not because of RTL
problems,
but simply because for people who only read Wikipedia this is inessential and for editors it is rather harmful.
Exactly how is this harmful? The only two problems you listed are a few missing toolbar buttons, which are easily added, and one buggy toolbar button which, by your own admission, you "can live with" (but which we'll of course fix ASAP).
I often write documentation for templates and having to type <nowiki></nowiki> all the time in examples of template usage is rather harmful, especially in the RTL environment of he.wp.
Will it be enabled in Wikisource, too? It doesn't work so well with the Proofread Page extension, which i use all the time.
In general, it would be less scary to hear the announcement that the Beta will so soon replace the current interface after the fixes to the important bugs in the Beta are actually deployed (line breaks in pasted text, image insertion in pasted text, etc.).
And don't get me wrong: I actually support interface updates, even if they are not very essential, and i do use the Beta most of the time in the last few weeks. I just think that it should be deployed after community discussion, and just forced on the community. Even if it's possible to go back to Monobook, it's still rather unpleasant; in fact, if a lot of people won't like it, it will especially unpleasant for the developers. For example, it will be much better to share problems with the Beta on a dedicated page in en.wp or on Meta, than to report them through the rather inconvenient "beta feedback" page. (And maybe such a page exists and i am making a fool of myself :)
The day this turn live, the Internet will become a bit crazy. Wikipedia is a important part of 2010 internet.
I am sure lots of people will want to put this skin on his suddenly old-looking wikipedias in internet and lans. You guys are doing a nice work.
note: I must report that the window "Add media wizard: Edit resource" don't "trim" the content of the "Caption" textarea prior to use, so If you put lots of \n there, end on the page.
note: Is worth putting a link "If you have problems with the new theme, please report then here?".
note: is maybe a matter of personal preference, but I think the main edit textarea could have a bit of padding, so the text can't touch the border of the textarea.
note: why textareas have vertical scrollbars?, maybe theres a way to dinamically change the height counting the number of \n inside the textarea. Of that is evil?
2010/3/26 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
Thanks.
Note, however, that if you add JS snippets, it may make it usable to me, but probably not quite usable to many people who don't want to learn to edit their vector.js. I've been editing Wikipedia for 5 years and i only created a personal JS file a few days ago.
It's not hard, given instructions, right? The instructions tell you the name of the page and exactly what to put into it, all you need to do is Ctrl+C, Edit, Ctrl+V, Save. I agree it's not the most intuitive thing in the world and gadgets are nicer (see below), but it's not rocket science either (as long as you don't have to write the JS yourself).
Making a GUI for adding buttons, at least through the "Gadgets" tab in the preferences, is essential.
It wouldn't be hard to implement the more popular buttons as Gadgets, we could do that I guess.
I often write documentation for templates and having to type <nowiki></nowiki> all the time in examples of template usage is rather harmful, especially in the RTL environment of he.wp.
I just heard we'll be adding a nowiki button in the stock toolbar, yay :)
Will it be enabled in Wikisource, too? It doesn't work so well with the Proofread Page extension, which i use all the time.
It will, yes. If you could file any bugs in the interaction between Vector and ProofreadPage in Bugzilla, that'd be great.
In general, it would be less scary to hear the announcement that the Beta will so soon replace the current interface after the fixes to the important bugs in the Beta are actually deployed (line breaks in pasted text, image insertion in pasted text, etc.).
The copypaste issues were the consequence of accidentally enabling the iframe editor for 36 hours. I disabled it again as soon as I figured out what was going wrong. I repeat: the iframe-based editor and the copypaste issues currently associated with it WILL NOT be part of the default rollout. Also, I trust bugfixes made to the beta in the next few weeks will be deployed quickly rather than waiting for the switchover.
For example, it will be much better to share problems with the Beta on a dedicated page in en.wp or on Meta, than to report them through the rather inconvenient "beta feedback" page. (And maybe such a page exists and i am making a fool of myself :)
You mean http://usability.wikimedia.org/wiki/Talk:Prototype ? Also, software bugs can and should be reported at bugzilla.wikimedia.org .
Roan Kattouw (Catrope)
On Fri, Mar 26, 2010 at 20:14, Roan Kattouw roan.kattouw@gmail.com wrote:
2010/3/26 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
Making a GUI for adding buttons, at least through the "Gadgets" tab in
the
preferences, is essential.
It wouldn't be hard to implement the more popular buttons as Gadgets, we could do that I guess.
It's essential. It is not too hard for me to edit vector.js, but most editors won't bother.
will so soon replace the current interface after the fixes to the
important
bugs in the Beta are actually deployed (line breaks in pasted text, image insertion in pasted text, etc.).
In general, it would be less scary to hear the announcement that the Beta
The copypaste issues were the consequence of accidentally enabling the iframe editor for 36 hours. I disabled it again as soon as I figured out what was going wrong. I repeat: the iframe-based editor and the copypaste issues currently associated with it WILL NOT be part of the default rollout. Also, I trust bugfixes made to the beta in the next few weeks will be deployed quickly rather than waiting for the switchover.
I am probably missing something. Is it enabled in the Beta now? Because i'm seeing the linebreaks bug now.
For example, it will be much better to share problems with the Beta on a dedicated page in en.wp or on Meta, than to report them through the
rather
inconvenient "beta feedback" page. (And maybe such a page exists and i am making a fool of myself :)
You mean http://usability.wikimedia.org/wiki/Talk:Prototype ?
Thanks. You hid it well :)
2010/3/26 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
I am probably missing something. Is it enabled in the Beta now? Because i'm seeing the linebreaks bug now.
Works fine for me, but we've had inconsistencies between Europe and the rest of the world before. I did what I usually do to fix that, hopefully it worked. Also, there seems to be a rogue sever not getting updates, if it's still in the server pool there's like a 1 in 200 chance you're getting your (outdated) JS from that box. Shift+Refresh should fix either issue.
Roan Kattouw (Catrope)
Hi! What's the purpose using of such links like [[/Title]] instead of [[Title]]? They probably should point to the same title. However, during the upgrade of one wikisite (from 1.11.2 to 1.15.2) I've found there were such titles in page table starting with slash, thus, inaccessible (at least with current rewrite rules). First thing, we thought that someone just mistyped the title, mistakingly placing starting slash in front of Title name during the new title creation. I've made such links invalid by changing value of $rxTc in Title::secureAndSplit() $rxTc = '/' . # Any character not allowed is forbidden... '[^' . Title::legalChars() . ']' . # URL percent encoding sequences interfere with the ability # to round-trip titles -- you can't link to them consistently. '|%[0-9A-Fa-f]{2}' . # XML/HTML character references produce similar issues. '|&[A-Za-z0-9\x80-\xff]+;' . '|&#[0-9]+;' . '|&#x[0-9A-Fa-f]+;' . '|^/' . # disable titles starting with slash character '/S'; for 1.15.2. However, later it was found that FCKeditor sometimes creates such links! Usually they point to correct titles, but the presence of titles with starting slash in page table makes me think that sometimes MediaWiki (at least in 1.11) allowed to create such entries. Should I file this to bugzilla, or that isn't worth thing? Dmitriy
2010/3/26 Dmitriy Sintsov questpc@rambler.ru:
Hi! What's the purpose using of such links like [[/Title]] instead of [[Title]]?
They're subpage links. If you're on [[Foo]], [[/Bar]] will point to [[Foo/Bar]] IF subpages are enabled in that namespace (only in talk namespaces and the template namespace by default).
Roan Kattouw (Catrope)
* Roan Kattouw roan.kattouw@gmail.com [Fri, 26 Mar 2010 21:11:47 +0100]:
They're subpage links. If you're on [[Foo]], [[/Bar]] will point to [[Foo/Bar]] IF subpages are enabled in that namespace (only in talk namespaces and the template namespace by default).
Thanks. I didn't knew that. Dmitriy
On 27/03/10 09:11, Roan Kattouw wrote:
2010/3/26 Dmitriy Sintsov questpc@rambler.ru:
What's the purpose using of such links like [[/Title]] instead of [[Title]]?
They're subpage links. If you're on [[Foo]], [[/Bar]] will point to [[Foo/Bar]] IF subpages are enabled in that namespace (only in talk namespaces and the template namespace by default).
I had expected it to work for transclusion as well, so that I could do {{:/nav}} to include a navigation header stored on a subpage without adding my page name explicitly (as in {{:Mypage/nav}}). Is there a way to do that?
Yes, just leave out the extraneous : you have included for some reason.
{{/nav}} will work nicely, if the namespace allows subpages.
If you'd like to see an amusing example of / in a namespace without subpages, see: http://en.wiktionary.org/wiki//
Robert
On Mon, Mar 29, 2010 at 3:05 AM, Jim Tittsler jt@onnz.net wrote:
On 27/03/10 09:11, Roan Kattouw wrote:
2010/3/26 Dmitriy Sintsov questpc@rambler.ru:
What's the purpose using of such links like [[/Title]] instead of [[Title]]?
They're subpage links. If you're on [[Foo]], [[/Bar]] will point to [[Foo/Bar]] IF subpages are enabled in that namespace (only in talk namespaces and the template namespace by default).
I had expected it to work for transclusion as well, so that I could do {{:/nav}} to include a navigation header stored on a subpage without adding my page name explicitly (as in {{:Mypage/nav}}). Is there a way to do that?
-- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/crew/jwt/ Mailman IRC irc://irc.freenode.net/#mailman
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
anyone got this kinds of issue:
when change the editor, the text area will show more no use's code just like"
<script type='text/javascript' language='JavaScript'> ; var addbuttonextension_iconpath='/wiki/extensions/AddButtonExtension' //global variable var buttonpara=new Array(); buttonpara[0]=new Array(function insertTag(){ insertTags("<font color="ColourName">","</font>","Text Color"); },"Button_font_color.png","Text Color"); buttonpara[1]=new Array(function insertTag(){ insertTags("{{strike|","}}","striked out"); },"strikebutton.jpg","Strike Out"); buttonpara[2]=new Array(function insertTag(){ insertTags("{{Comment|","}}","Comment"); },"commentbutton.jpg","Comment Out"); </script> <!--- START AddButtonExtension JavaScript --> <script type='text/javascript' language='JavaScript'> //_____________________________________________________________________ // copyright 2006 Assela Pathirana // UNDER GNU GPL //____version .2 _________________________________________________________________ //
and so on,
it seems that it's a extension issues. who can help me??? Thanks!
Evel.
2010/3/29 Robert Ullmann rlullmann@gmail.com
Yes, just leave out the extraneous : you have included for some reason.
{{/nav}} will work nicely, if the namespace allows subpages.
If you'd like to see an amusing example of / in a namespace without subpages, see: http://en.wiktionary.org/wiki//
Robert
On Mon, Mar 29, 2010 at 3:05 AM, Jim Tittsler jt@onnz.net wrote:
On 27/03/10 09:11, Roan Kattouw wrote:
2010/3/26 Dmitriy Sintsov questpc@rambler.ru:
What's the purpose using of such links like [[/Title]] instead of [[Title]]?
They're subpage links. If you're on [[Foo]], [[/Bar]] will point to [[Foo/Bar]] IF subpages are enabled in that namespace (only in talk namespaces and the template namespace by default).
I had expected it to work for transclusion as well, so that I could do {{:/nav}} to include a navigation header stored on a subpage without adding my page name explicitly (as in {{:Mypage/nav}}). Is there a way to do that?
-- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/crew/jwt/ Mailman IRC irc://irc.freenode.net/#mailman
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
At Wikisource, we would be wanting to install tools in batches, and often dependent on the namespace, so we would be looking to gadgetise, or some other readily available means. Also as some works/projects upon which people undertake have repetitive editing, so we would be looking to enable people to easily configure for their works of interest, even to the point of being able to look to produce certain tools per work/project.
We see that being able to produce tools that are ideal for a work or a project enables us to make certain transcriptions more appetising to the casual editor.
Regards Andrew
On 26 Mar 2010 at 18:14, Roan Kattouw wrote:
2010/3/26 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
Thanks.
Note, however, that if you add JS snippets, it may make it usable to me, but probably not quite usable to many people who don't want to learn to edit their vector.js. I've been editing Wikipedia for 5 years and i only created a personal JS file a few days ago.
It's not hard, given instructions, right? The instructions tell you the name of the page and exactly what to put into it, all you need to do is Ctrl+C, Edit, Ctrl+V, Save. I agree it's not the most intuitive thing in the world and gadgets are nicer (see below), but it's not rocket science either (as long as you don't have to write the JS yourself).
Making a GUI for adding buttons, at least through the "Gadgets" tab in the preferences, is essential.
It wouldn't be hard to implement the more popular buttons as Gadgets, we could do that I guess.
I often write documentation for templates and having to type <nowiki></nowiki> all the time in examples of template usage is rather harmful, especially in the RTL environment of he.wp.
I just heard we'll be adding a nowiki button in the stock toolbar, yay :)
Will it be enabled in Wikisource, too? It doesn't work so well with the Proofread Page extension, which i use all the time.
It will, yes. If you could file any bugs in the interaction between Vector and ProofreadPage in Bugzilla, that'd be great.
In general, it would be less scary to hear the announcement that the Beta will so soon replace the current interface after the fixes to the important bugs in the Beta are actually deployed (line breaks in pasted text, image insertion in pasted text, etc.).
The copypaste issues were the consequence of accidentally enabling the iframe editor for 36 hours. I disabled it again as soon as I figured out what was going wrong. I repeat: the iframe-based editor and the copypaste issues currently associated with it WILL NOT be part of the default rollout. Also, I trust bugfixes made to the beta in the next few weeks will be deployed quickly rather than waiting for the switchover.
For example, it will be much better to share problems with the Beta on a dedicated page in en.wp or on Meta, than to report them through the rather inconvenient "beta feedback" page. (And maybe such a page exists and i am making a fool of myself :)
You mean http://usability.wikimedia.org/wiki/Talk:Prototype ? Also, software bugs can and should be reported at bugzilla.wikimedia.org .
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
Just for curiosity, can we know the beta retention rate for huwiki?
Thanks, Akos
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in occasional blog posts.
On Sat, Mar 27, 2010 at 11:01, Glanthor glanthor@gmail.com wrote:
Hi!
Just for curiosity, can we know the beta retention rate for huwiki?
Thanks, Akos
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/3/28 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in occasional blog posts.
The raw data is at http://toolserver.org/~catrope/optin-20100217/ and similar URLs for every other day since Feb 1, 2010. The script generating this data broke recently, so the data for the second half of March is probably wrong.
Roan Kattouw (Catrope)
I would look at the statistics published here:
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
Cheers,
Ariel
Στις 28-03-2010, ημέρα Κυρ, και ώρα 02:08 +0300, ο/η Amir E. Aharoni έγραψε:
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in occasional blog posts.
On Sat, Mar 27, 2010 at 11:01, Glanthor glanthor@gmail.com wrote:
Hi!
Just for curiosity, can we know the beta retention rate for huwiki?
Thanks, Akos
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
<אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
"We're living in pieces, I want to live in peace." - T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
There is also a spreadsheet at https://spreadsheets.google.com/ccc?key=0Aikdcg5HdSKbdDVMM2l2SGM2dUtBU25MLUt...
I wonder if the user comments and survey results for the Hungarian Wikipedia are available anywhere? Hungarian is not included in the nice tables I found on usability wiki, yet the retention rate is just below 60%.
Best regards, Bence Damokos
On 28 March 2010 00:23, Ariel T. Glenn ariel@wikimedia.org wrote:
I would look at the statistics published here:
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
Cheers,
Ariel
Στις 28-03-2010, ημέρα Κυρ, και ώρα 02:08 +0300, ο/η Amir E. Aharoni έγραψε:
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in occasional blog posts.
On Sat, Mar 27, 2010 at 11:01, Glanthor glanthor@gmail.com wrote:
Hi!
Just for curiosity, can we know the beta retention rate for huwiki?
Thanks, Akos
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
<אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
"We're living in pieces, I want to live in peace." - T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Bence Damokos <bdamokos <at> gmail.com> writes:
There is also a spreadsheet at https://spreadsheets.google.com /ccc?key=0Aikdcg5HdSKbdDVMM2l2SGM2dUtBU25MLUtTMFEwMFE&hl=hu
I wonder if the user comments and survey results for the Hungarian Wikipedia are available anywhere? Hungarian is not included in the nice tables I found on usability wiki, yet the retention rate is just below 60%.
Data until Oct. 29 is apparently available at http://toolserver.org/~catrope/survey/
Bence Damokos wrote:
There is also a spreadsheet at https://spreadsheets.google.com/ccc?key=0Aikdcg5HdSKbdDVMM2l2SGM2dUtBU25MLUt...
I wonder if the user comments and survey results for the Hungarian Wikipedia are available anywhere? Hungarian is not included in the nice tables I found on usability wiki, yet the retention rate is just below 60%.
Best regards, Bence Damokos
Hi, Bence.
We can make the user comments from the Hungarain Wikipedia available along with other languages here, if there is an interest in reviewing the comments in Hungarian.
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey/User_Comments
We used the Google Translation to translate the comments for the ten languages prioritized by the size of traffic and the frequency of the beta usage.
Best,
- Naoko
On 28 March 2010 00:23, Ariel T. Glenn ariel@wikimedia.org wrote:
I would look at the statistics published here:
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
Cheers,
Ariel
Στις 28-03-2010, ημέρα Κυρ, και ώρα 02:08 +0300, ο/η Amir E. Aharoni έγραψε:
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in occasional blog posts.
On Sat, Mar 27, 2010 at 11:01, Glanthor glanthor@gmail.com wrote:
Hi!
Just for curiosity, can we know the beta retention rate for huwiki?
Thanks, Akos
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
<אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
"We're living in pieces, I want to live in peace." - T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Naoko, Thank you, I think the interest is there. I have been looking at some of the raw data from the end of October but a more human readable format would really help to get the picture instead of some individual comments (e.g. missing toolbar buttons, not working gadgets/WikiEd, can't find the watch button).
(Note that a portion of the comments are indeed in English and it would be really nice if you made the original Hungarian comments available as well alongside any machine translation.)
Best regards, Bence
On 28 March 2010 19:14, Naoko Komura nkomura@wikimedia.org wrote:
Bence Damokos wrote:
There is also a spreadsheet at
https://spreadsheets.google.com/ccc?key=0Aikdcg5HdSKbdDVMM2l2SGM2dUtBU25MLUt...
I wonder if the user comments and survey results for the Hungarian
Wikipedia
are available anywhere? Hungarian is not included in the nice tables I
found
on usability wiki, yet the retention rate is just below 60%.
Best regards, Bence Damokos
Hi, Bence.
We can make the user comments from the Hungarain Wikipedia available along with other languages here, if there is an interest in reviewing the comments in Hungarian.
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey/User_Comments
We used the Google Translation to translate the comments for the ten languages prioritized by the size of traffic and the frequency of the beta usage.
Best,
- Naoko
On 28 March 2010 00:23, Ariel T. Glenn ariel@wikimedia.org wrote:
I would look at the statistics published here:
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
Cheers,
Ariel
Στις 28-03-2010, ημέρα Κυρ, και ώρα 02:08 +0300, ο/η Amir E. Aharoni έγραψε:
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in
occasional
blog posts.
On Sat, Mar 27, 2010 at 11:01, Glanthor glanthor@gmail.com wrote:
Hi!
Just for curiosity, can we know the beta retention rate for huwiki?
Thanks, Akos
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
<אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
"We're living in pieces, I want to live in peace." - T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Bence Damokos wrote:
Hi Naoko, Thank you, I think the interest is there. I have been looking at some of the raw data from the end of October but a more human readable format would really help to get the picture instead of some individual comments (e.g. missing toolbar buttons, not working gadgets/WikiEd, can't find the watch button).
(Note that a portion of the comments are indeed in English and it would be really nice if you made the original Hungarian comments available as well alongside any machine translation.)
Best regards, Bence
OK, let us clean up the raw data file and upload the survey comments for hu.wp in Hungarian with the machine translation to English. You can tell us how good or bad the machine translation is. :-)
- Naoko
Bence Damokos wrote:
Hi Naoko, Thank you, I think the interest is there. I have been looking at some of the raw data from the end of October but a more human readable format would really help to get the picture instead of some individual comments (e.g. missing toolbar buttons, not working gadgets/WikiEd, can't find the watch button).
(Note that a portion of the comments are indeed in English and it would be really nice if you made the original Hungarian comments available as well alongside any machine translation.)
Best regards, Bence
Hi, Bence.
The survey feedback from the Hungarian Wikipedia is now available with English translation.
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey/User_Comments If the wiki page is too slow to load, you can go to the survey page directly. http://biturl.cc/bWQ
The data only covers till December for now.
We will review the translated comments, but if you find the machine translation is horribly broken, please give us a holler.
Best,
- Naoko
On 28 March 2010 19:14, Naoko Komura nkomura@wikimedia.org wrote:
Bence Damokos wrote:
There is also a spreadsheet at
https://spreadsheets.google.com/ccc?key=0Aikdcg5HdSKbdDVMM2l2SGM2dUtBU25MLUt...
I wonder if the user comments and survey results for the Hungarian
Wikipedia
are available anywhere? Hungarian is not included in the nice tables I
found
on usability wiki, yet the retention rate is just below 60%.
Best regards, Bence Damokos
Hi, Bence.
We can make the user comments from the Hungarain Wikipedia available along with other languages here, if there is an interest in reviewing the comments in Hungarian.
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey/User_Comments
We used the Google Translation to translate the comments for the ten languages prioritized by the size of traffic and the frequency of the beta usage.
Best,
- Naoko
On 28 March 2010 00:23, Ariel T. Glenn ariel@wikimedia.org wrote:
I would look at the statistics published here:
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
Cheers,
Ariel
Στις 28-03-2010, ημέρα Κυρ, και ώρα 02:08 +0300, ο/η Amir E. Aharoni έγραψε:
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in
occasional
blog posts.
On Sat, Mar 27, 2010 at 11:01, Glanthor glanthor@gmail.com wrote:
Hi!
Just for curiosity, can we know the beta retention rate for huwiki?
Thanks, Akos
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
<אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
"We're living in pieces, I want to live in peace." - T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Naoko Komura wrote:
Bence Damokos wrote:
Hi Naoko, Thank you, I think the interest is there. I have been looking at some of the raw data from the end of October but a more human readable format would really help to get the picture instead of some individual comments (e.g. missing toolbar buttons, not working gadgets/WikiEd, can't find the watch button).
(Note that a portion of the comments are indeed in English and it would be really nice if you made the original Hungarian comments available as well alongside any machine translation.)
Best regards, Bence
Hi, Bence.
The survey feedback from the Hungarian Wikipedia is now available with English translation.
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey/User_Comments If the wiki page is too slow to load, you can go to the survey page directly. http://biturl.cc/bWQ
The data only covers till December for now.
We will review the translated comments, but if you find the machine translation is horribly broken, please give us a holler.
Best,
- Naoko
I forgot to mention that the survey and the translation integration was made available by Roan Kattouw, Nimish Gautam and Howie Fung.
Thanks guys. You rock. :-)
- Naoko
On 28 March 2010 19:14, Naoko Komura nkomura@wikimedia.org wrote:
Bence Damokos wrote:
There is also a spreadsheet at
https://spreadsheets.google.com/ccc?key=0Aikdcg5HdSKbdDVMM2l2SGM2dUtBU25MLUt...
I wonder if the user comments and survey results for the Hungarian
Wikipedia
are available anywhere? Hungarian is not included in the nice tables I
found
on usability wiki, yet the retention rate is just below 60%.
Best regards, Bence Damokos
Hi, Bence.
We can make the user comments from the Hungarain Wikipedia available along with other languages here, if there is an interest in reviewing the comments in Hungarian.
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey/User_Comments
We used the Google Translation to translate the comments for the ten languages prioritized by the size of traffic and the frequency of the beta usage.
Best,
- Naoko
On 28 March 2010 00:23, Ariel T. Glenn ariel@wikimedia.org wrote:
I would look at the statistics published here:
http://usability.wikimedia.org/wiki/Beta_Feedback_Survey
Cheers,
Ariel
Στις 28-03-2010, ημέρα Κυρ, και ώρα 02:08 +0300, ο/η Amir E. Aharoni έγραψε:
I join Akos - are complete statistics about Beta usage in all projects published anywhere? Until now i only saw occasional numbers in
occasional
blog posts.
On Sat, Mar 27, 2010 at 11:01, Glanthor glanthor@gmail.com wrote:
> Hi! > > Just for curiosity, can we know the beta retention rate for huwiki? > > Thanks, > Akos > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > >
>
<אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
"We're living in pieces, I want to live in peace." - T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks Naoko, Roan, Nimish, Howie we'll look into the comments, maybe we can solve some of the common problems on our end (e.g., some incompatible gadgets).
Best, Bence
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Is there any documentation for converting monobook-ish js to vector-ish js?
- -Mike
Hi! May I ask a feature request: keyboard shortcut Ctrl+Enter should be used to submit edited article. Such way small changes would be faster to input, not having to click "Save page" button. Many forums and web engines support such accelerated submission via Ctrl+Enter. Dmitriy
On Thu, Apr 1, 2010 at 09:35, Dmitriy Sintsov questpc@rambler.ru wrote:
Hi! May I ask a feature request: keyboard shortcut Ctrl+Enter should be used to submit edited article. Such way small changes would be faster to input, not having to click "Save page" button. Many forums and web engines support such accelerated submission via Ctrl+Enter. Dmitriy
I haven't tried out any of the newer skins, but I think Alt-S (may be Ctrl-Alt-S or so depending on your browser's configuration) can already be used for saving; similarly, Alt-P (or Ctrl-Alt-P etc.) can already be used for previewing.
Looking at the feedback in Hungarian I seem to notice some common problems that might be solved (or have been already solved) or should be considered by the usability team.
Many people have reported problems because the section edit links tended to end up next to each other on one line if the pictures in the article overlapped with section boundaries - most people found this confusing and some reported engaging in a serious of futile edits to correct this problem. I am not sure, but it seems that these links are now moved to be next to the section titles which solves this problem. (To verify this, I could recommend [[hu:Kolbász]] with quite a few pictures.) (If this is a huwiki specific JS or CSS solution, you should consider the problem for wikis where the translation of [edit] is significantly longer than the English equivalent, which might lead to a higher chance of conflict with images.)
There were some comments about speed as well, some seem to have complained of not having found the toolbar (I guess the JS generating the toolbar didn't load for them quickly enough or at all).
Someone using IE8 complained that he was constantly getting "This site has an error" type of notifications with the page -- this, I hope, has been fixed since (since 2009-12-01).
As mentioned earlier, and maybe in this thread, people were missing WikiEd and Hotcat compatibility, as well as compatibility with a gadget that allowed opening the search results in a new tab.
I personally am missing the possibility to update the built in special characters box (here thinking about adding a section for wiki specific tags, clean-up templates, or HTML tags). Also, the buttons (under Advanced) to make redirects ("#redirect [[ ]]") or to add a references section. I think these two latter are common enough to be had by default under advanced (maybe with a little dialogue showing current redirects to the page and making it possible to create new ones in the background with an explanatory text about the common cases when one would want to do this [hyphenation, spelling variants]).
Best regards, Bence
On Thu, Apr 1, 2010 at 1:08 PM, Schneelocke schneelocke@gmail.com wrote:
On Thu, Apr 1, 2010 at 09:35, Dmitriy Sintsov questpc@rambler.ru wrote:
Hi! May I ask a feature request: keyboard shortcut Ctrl+Enter should be used to submit edited article. Such way small changes would be faster to input, not having to click "Save page" button. Many forums and web engines support such accelerated submission via Ctrl+Enter. Dmitriy
I haven't tried out any of the newer skins, but I think Alt-S (may be Ctrl-Alt-S or so depending on your browser's configuration) can already be used for saving; similarly, Alt-P (or Ctrl-Alt-P etc.) can already be used for previewing.
-- schnee
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Apr 1, 2010 at 22:11, Bence Damokos bdamokos@gmail.com wrote:
Many people have reported problems because the section edit links tended to end up next to each other on one line if the pictures in the article overlapped with section boundaries - most people found this confusing and some reported engaging in a serious of futile edits to correct this problem. I am not sure, but it seems that these links are now moved to be next to the section titles which solves this problem.
This happens in Monobook too, for ages. In English and Hebrew, too. I hoped that Vector would solve it, but it didn't.
It is broken in Chrome and in Firefox on XP, Vista and Ubuntu. Strangely, it is broken in IE8 on XP, but it is *not* broken in IE8 on Vista.
2010/4/1 Bence Damokos bdamokos@gmail.com:
Many people have reported problems because the section edit links tended to end up next to each other on one line if the pictures in the article overlapped with section boundaries - most people found this confusing and some reported engaging in a serious of futile edits to correct this problem. I am not sure, but it seems that these links are now moved to be next to the section titles which solves this problem. (To verify this, I could recommend [[hu:Kolbász]] with quite a few pictures.) (If this is a huwiki specific JS or CSS solution, you should consider the problem for wikis where the translation of [edit] is significantly longer than the English equivalent, which might lead to a higher chance of conflict with images.)
Per Amir's post, this is a long-standing issue caused by the positioning of the edit links. We had plans and even have code to move the edit links to right next to the headers (dewiki-style, if you will), which would solve this, but that somehow got buried in other work.
There were some comments about speed as well, some seem to have complained of not having found the toolbar (I guess the JS generating the toolbar didn't load for them quickly enough or at all).
Someone using IE8 complained that he was constantly getting "This site has an error" type of notifications with the page -- this, I hope, has been fixed since (since 2009-12-01).
We've been fixing JS errors and performance problems all the time, and the toolbar should be pretty solid now. I'll run another round of profiling against it for paranoia, but I've already squeezed it quite a bit in the past so I'm not sure how much there's to gain there. Migrating to jQuery 1.4 (with much faster DOM manipulation, which is the toolbar's main bottleneck) is on our nice-to-have list; some of our plugin code currently causes weird issues with 1.4, we have to sort those out.
As mentioned earlier, and maybe in this thread, people were missing WikiEd and Hotcat compatibility, as well as compatibility with a gadget that allowed opening the search results in a new tab.
Fixing community-written gadgets is technically not our responsibility. We may end up fixing a few of them ourselves if we're told to, but I can't promise anythng (talk to my boss, not to me :) ).
I personally am missing the possibility to update the built in special characters box (here thinking about adding a section for wiki specific tags, clean-up templates, or HTML tags).
You can do this in e.g. MediaWiki:Common.js . There's some documentation on extending the toolbar in general at http://usability.wikimedia.org/wiki/Toolbar_customization which I will update to contain more explicit guides to customizing the special characters part.
Also, the buttons (under Advanced) to make redirects ("#redirect [[ ]]") or to add a references section. I think these two latter are common enough to be had by default under advanced
We're planning on adding a nowiki and redirect button, and we've made a simple dialog for inserting and adding references. Adding a references *section* is a good catch, I'll bring that up. These changes have already been made in SVN and are staged at http://prototype.wikimedia.org/s-1/index.php?title=Foo&action=edit
(maybe with a little dialogue showing current redirects to the page and making it possible to create new ones in the background with an explanatory text about the common cases when one would want to do this [hyphenation, spelling variants]).
I guess that'd be cool, but it's probably also out of the scope of this project: creating redirects is not one of the main things we expect new editors to do, I think.
Roan Kattouw (Catrope)
Bence Damokos wrote:
Looking at the feedback in Hungarian I seem to notice some common problems that might be solved (or have been already solved) or should be considered by the usability team.
Many people have reported problems because the section edit links tended to end up next to each other on one line if the pictures in the article overlapped with section boundaries - most people found this confusing and some reported engaging in a serious of futile edits to correct this problem. I am not sure, but it seems that these links are now moved to be next to the section titles which solves this problem. (To verify this, I could recommend [[hu:Kolbász]] with quite a few pictures.) (If this is a huwiki specific JS or CSS solution, you should consider the problem for wikis where the translation of [edit] is significantly longer than the English equivalent, which might lead to a higher chance of conflict with images.)
There were some comments about speed as well, some seem to have complained of not having found the toolbar (I guess the JS generating the toolbar didn't load for them quickly enough or at all).
Someone using IE8 complained that he was constantly getting "This site has an error" type of notifications with the page -- this, I hope, has been fixed since (since 2009-12-01).
As mentioned earlier, and maybe in this thread, people were missing WikiEd and Hotcat compatibility, as well as compatibility with a gadget that allowed opening the search results in a new tab.
I personally am missing the possibility to update the built in special characters box (here thinking about adding a section for wiki specific tags, clean-up templates, or HTML tags). Also, the buttons (under Advanced) to make redirects ("#redirect [[ ]]") or to add a references section. I think these two latter are common enough to be had by default under advanced (maybe with a little dialogue showing current redirects to the page and making it possible to create new ones in the background with an explanatory text about the common cases when one would want to do this [hyphenation, spelling variants]).
Best regards, Bence
Dear Bence,
Thank you so much for summarizing the feedback from Hungarian Wikipedians. As Roan replied to you, some of the features often requested such as "nowiki" and "redirect" are incorporated and will be available when the update is released next week.
Thanks again,
- Naoko
Mike.lifeguard wrote:
Is there any documentation for converting monobook-ish js to vector-ish js?
The first step is generally to try and see if it'll Just Work(TM). Most of my scripts[1], though originally written for Monobook, seem to work just fine under Vector. (There used to be some minor incompatibilities with portlets, but these have mostly been fixed.)
The most common cause of failure that I've seen seems to be looking for elements with IDs that are present in Monobook but not in Vector. There aren't that many, since the Vector skin deliberately tries to use the same IDs as Monobook where possible, but sometimes you may have to choose a different ID or make it conditional on the skin used.
The one thing that's really different and incompatible isn't really a part of the skin but the new edit toolbar. I had to rewrite my sigdash script completely from scratch because of that. Also, I should note that none of my scripts really approach the complexity of things like Twinkle or WikEd etc., and such complex scripts may well encounter issues that I haven't really noticed.
[1] http://en.wikipedia.org/wiki/User:Ilmari_Karonen/scripts
* Ilmari Karonen nospam@vyznev.net [Sat, 03 Apr 2010 21:30:47 +0300]:
The one thing that's really different and incompatible isn't really a part of the skin but the new edit toolbar. I had to rewrite my
sigdash
script completely from scratch because of that. Also, I should note that none of my scripts really approach the complexity of things like Twinkle or WikEd etc., and such complex scripts may well encounter issues that I haven't really noticed.
I've thought that minimal version of syntax highlighting and some another WikEd features are in Extension:UsabilityInitiative (with some additional parameters in LocalSettings.php), but these weren't working for me in early betas. I will try to update from trunk at work in monday, to see whether it will work. Dmitriy
2010/4/4 Dmitriy Sintsov questpc@rambler.ru:
I've thought that minimal version of syntax highlighting and some another WikEd features are in Extension:UsabilityInitiative (with some additional parameters in LocalSettings.php), but these weren't working for me in early betas. I will try to update from trunk at work in monday, to see whether it will work.
We have the technical framework for syntax highlighting and did indeed highlight headers at some point, but we decided to drop that until we have time to figure out a comprehensive approach to syntax highlighting (in terms of what should be styled how).
Roan Kattouw (Catrope)
Roan Kattouw wrote:
2010/3/26 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
Thanks.
Note, however, that if you add JS snippets, it may make it usable to me, but probably not quite usable to many people who don't want to learn to edit their vector.js. I've been editing Wikipedia for 5 years and i only created a personal JS file a few days ago.
It's not hard, given instructions, right? The instructions tell you the name of the page and exactly what to put into it, all you need to do is Ctrl+C, Edit, Ctrl+V, Save. I agree it's not the most intuitive thing in the world and gadgets are nicer (see below), but it's not rocket science either (as long as you don't have to write the JS yourself).
Why not support the existing mwCustomEditButtons ? They habe been there since April 2006. Additionally, adding a Special page for gui adding of toolbar buttons with your personal js as backend seems a good idea.
Roan Kattouw <roan.kattouw <at> gmail.com> writes:
That's deliberate, the TOC requires the iframe, which was disabled because of copy-paste issues. We're also not enabling NTOC as a default feature, so this is irrelevant.
Does that mean the iframe-based editor will not be enabled? It sounds much less scary that way :) It still has a number of small but annoying bugs - the edit box scrolling away on copy/paste, unexpected blurs, unresponsiveness when loading, etc.
The Vector skin itself, on the other hand, seems mature - it will be cool to have it as default. (Does that mean that users who have never touched their skin settings will automatically get it too, or only those who register in the future?)
2010/3/26 Tisza Gergő gtisza@gmail.com:
Roan Kattouw <roan.kattouw <at> gmail.com> writes:
That's deliberate, the TOC requires the iframe, which was disabled because of copy-paste issues. We're also not enabling NTOC as a default feature, so this is irrelevant.
Does that mean the iframe-based editor will not be enabled? It sounds much less scary that way :) It still has a number of small but annoying bugs - the edit box scrolling away on copy/paste, unexpected blurs, unresponsiveness when loading, etc.
Yes, that's what it means. The iframe-based editor will NOT be enabled by default. Once we stabilize it a little bit more, it will probably be enabled for users who enable certain experimental features of ours in their preferences, but at least those users explicitly took action to enable it and know how to disable it again.
The Vector skin itself, on the other hand, seems mature - it will be cool to have it as default. (Does that mean that users who have never touched their skin settings will automatically get it too, or only those who register in the future?)
Yes, every user whose skin preference is set to Monobook (including users who never changed their skin pref) will automatically be switched over, and every newly created account will have Vector as their initial skin preference. Users whose skin is set to some third skin (not Monobook or Vector) will be left alone. Also, as I mentioned just before, there'll be a quick "Take me back" link to go back to Monobook.
Roan Kattouw (Catrope)
On 26.03.2010, 16:30 Roan wrote:
Because Opera is broken is subtle ways that make it very difficult to get S&R to work right. We could either enable a broken version of S&R in Opera and be yelled at because it corrupts wikitext (very bad) or disable the feature in Opera (less bad). In the future, S&R should work in Opera as well.
Speaking of Opera, it seems seems to have many bugs causing troubles for UI, such as https://bugzilla.wikimedia.org/show_bug.cgi?id=21537. Can we produce reduced test cases and report them to Opera? After all, their CTO Hakon Wium Lie posted to this list, so apparently they are interested in making their browser run smoothly on world's 6th website.
On Fri, Mar 26, 2010 at 11:32 AM, Max Semenik maxsem.wiki@gmail.com wrote:
Speaking of Opera, it seems seems to have many bugs causing troubles for UI, such as https://bugzilla.wikimedia.org/show_bug.cgi?id=21537. Can we produce reduced test cases and report them to Opera? After all, their CTO Hakon Wium Lie posted to this list, so apparently they are interested in making their browser run smoothly on world's 6th website.
You can report Opera bugs here:
https://bugs.opera.com/wizard/
It goes to some internal closed tracker and you never receive a response.
The dialogs in the new toolbar seem to be disabled in IE8, is this something that will be changed before deployment?
2010/3/27 Alex mrzmanwiki@gmail.com:
The dialogs in the new toolbar seem to be disabled in IE8, is this something that will be changed before deployment?
Yes. We discovered they had new IE bugs in a fairly late stage, so rather than delaying the deployment we decided to deploy them without IE support. We're working out the IE bugs and will deploy the fixes as soon as we can.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org