Reply to message 7
Seems it can use anywhere but it not support Chinese at least. It do not support the http://en.wikipedia.org/wiki/Chinese_input_methods_for_computers . May it be fix?
HW
________________________________ 寄件人﹕ "wikitech-l-request@lists.wikimedia.org" wikitech-l-request@lists.wikimedia.org 收件人﹕ wikitech-l@lists.wikimedia.org 傳送日期﹕ 2011/1/23 (日) 9:40:33 AM 主題： Wikitech-l Digest, Vol 90, Issue 48
Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Wikitech-l digest..."
Today's Topics:
1. Re: File licensing information support (Bryan Tong Minh) 2. Re: File licensing information support (Platonides) 3. Re: Announcing OpenStackManager extension (Platonides) 4. Re: File licensing information support (Krinkle) 5. Re: File licensing information support (Platonides) 6. Re: File licensing information support (Magnus Manske) 7. Re: WYSIFTW status (Magnus Manske) 8. Re: Farewell JSMin, Hello JavaScriptDistiller! (Maciej Jaros)
----------------------------------------------------------------------
Message: 1 Date: Sat, 22 Jan 2011 20:15:10 +0100 From: Bryan Tong Minh bryan.tongminh@gmail.com Subject: Re: [Wikitech-l] File licensing information support To: Wikimedia developers wikitech-l@lists.wikimedia.org Message-ID: AANLkTinN_n3kM0s_yCymh5jySu47h8mtdAqZX9bxPCnB@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1
On Fri, Jan 21, 2011 at 3:36 AM, Michael Dale mdale@wikimedia.org wrote:
On 01/20/2011 05:00 PM, Platonides wrote:
I would have probably gone by the page_props route, passing the metadata from the wikitext to the tables via a parser function.
I would also say its probably best to pass metadata from the wikitext to the tables via a parser function. ?Similar to categories, and all other "user edited" metadata. This has the disadvantage that its not easy 'as easy' to edit via structured api entry point, ?but has the advantage of working well with all the existing tools, templates and versioning.
This is actually the biggest decision that has been made, the rest is mostly implementation details. (Please note that I'm not presenting you with a fait accompli, it is of course still possible to change this)
Handling metadata separately from wikitext provides two main advantages: it is much more user friendly, and it allows us to properly validate and parse data.
Having a clear separate input text field "Author: ____" is much more user friendly {{#fileauthor:}}, which is so to say, a type of obscure MediaWiki jargon. I know that we could probably hide it behind a template, but that is still not as friendly as a separate field. I keep on hearing that especially for newbies, a big blob of wikitext is plain scary. We regulars may be able to quickly parse the structure in {{Information}}, but for newbies this is certainly not so clear. We actually see that from the community there is a demand for separating the meta data from the wikitext -- this is after all why they implemented the uselang= hacked upload form with a separate text box for every meta field.
Also, a separate field allows MediaWiki to understand what a certain input really means. {{#fileauthor:[[User:Bryan]]}} means nothing to MediaWiki or re-users, but "Author: Bryan___ [checkbox] This is a Commons username" can be parsed by MediaWiki to mean something. It also allows us to mass change for example the author. If I want to change my attribution from "Bryan" to "Bryan Tong Minh", I would need to edit the wikitext of every single upload, whereas in the new system I go to Special:AuthorManager and change the attribution.
Similar to categories, and all other"user edited" metadata.
Categories is a good example of why metadata does not belong in the wikitext. If you have ever tried renaming a category... you need to edit every page in the category and rename it in the wikitext. Commons is running multiple bots to handle category rename requests.
All these advantage outweigh the pain of migration (which could presumably be handled by bots) in my opinion.
Best regards, Bryan
------------------------------
Message: 2 Date: Sat, 22 Jan 2011 21:04:05 +0100 From: Platonides Platonides@gmail.com Subject: Re: [Wikitech-l] File licensing information support To: wikitech-l@lists.wikimedia.org Message-ID: ihfd31$buv$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
An internally handled parser function doesn't conflict with showing it as a textbox.
We could for instance store it as a hidden page prefix.
Data stored in the text blob: "Author: [[Author:Bryan]] License: GPL --- {{Information| This is a nice picture I took }} {{Deletion request|Copyvio from http://www.example.org%7D%7D "
Data shown when clicking edit:
Author: <input type="text value="Bryan" /> License: <select>GPL</select>
<textarea name="textbox1"> {{Information| This is a nice picture I took }} {{Deletion request|Copyvio from http://www.example.org%7D%7D </textarea>
Why do I like such approach? * You don't need to create a new way for storing the history of such metadata. * Old versions are equally viewable. * Things like edit conflicts are already handled. * Diffing could be done directly with the blobs. * Import/export automatically works. * Extendable for more metadata. * Readable for tools/wikis unaware of the new format.
On the other hand: * It breaks the concept of "everything is in the source". * Parsing is different based on the namespace. A naive parsing as "License: GPL" instead of showing an image and a GPL excerpt, would be acceptable, but if incomplete markup is stored there, the renderings would be completely different. Could be skipped if placing the metadata inside a tag. But what happens if the tag is inserted elsewhere in the page? MediaWiki doesn't have run-once tags.
PS: The field author would be just a pointer to the author page, so you wouldn't need to edit everything on any case.
------------------------------
Message: 3 Date: Sat, 22 Jan 2011 21:05:57 +0100 From: Platonides Platonides@gmail.com Subject: Re: [Wikitech-l] Announcing OpenStackManager extension To: wikitech-l@lists.wikimedia.org Cc: mediawiki-l@lists.wikimedia.org Message-ID: ihfd6h$buv$2@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
Ryan Lane wrote:
For the past month or so I've been working on an extension to manage OpenStack (Nova), for use on the Wikimedia Foundation's upcoming virtualization cluster:
http://ryandlane.com/blog/2011/01/02/building-a-test-and-development-infrast... /
I've gotten to a point where I believe the extension is ready for an initial release.
Congratulations, Ryan!
------------------------------
Message: 4 Date: Sat, 22 Jan 2011 21:47:17 +0100 From: Krinkle krinklemail@gmail.com Subject: Re: [Wikitech-l] File licensing information support To: Wikimedia developers wikitech-l@lists.wikimedia.org Message-ID: 37ECD06F-DF37-4F62-9CA2-1DC62EC267BA@gmail.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Jan 22, 2011 at 21:04 Platonides wrote:
An internally handled parser function doesn't conflict with showing it as a textbox.
We could for instance store it as a hidden page prefix.
Data stored in the text blob: "Author: [[Author:Bryan]] License: GPL
{{Information| This is a nice picture I took }} {{Deletion request|Copyvio from http://www.example.org%7D%7D "
Data shown when clicking edit:
Author: <input type="text value="Bryan" /> License: <select>GPL</select>
<textarea name="textbox1"> {{Information| This is a nice picture I took }} {{Deletion request|Copyvio from http://www.example.org}} </textarea>
So PHP would extract {{#author:4}} and {{#license:12}} from the textblob when showing the editpage. And show the remaining wikitext in the <textarea> and the author/ license as seperate form elements. And upon saving, generate "{{#author:4}} {{#license:12}}\n" again and prepend to the textblob.
Double instances of these would be ignored (ie. stripped automatically since they're not re-inserted to the textblob upon saving). One small downside would be that if someone would edit the textarea manually to do stuff with author and license, the next edit would re-arrange them since they're extracted and re-insterted thus showing messy diffs. (not a major point as long as it's done independant from JavaScript, which it can be if done from core / php).
If that's what you meant, I think it is an interesting concept that should not be ignored, however personally I am not yet convinced this is the way to go. But when looking at the complete picture of up/down sides, this could be something to consider.
-- Krinkle
------------------------------
Message: 5 Date: Sat, 22 Jan 2011 23:09:59 +0100 From: Platonides Platonides@gmail.com Subject: Re: [Wikitech-l] File licensing information support To: wikitech-l@lists.wikimedia.org Message-ID: ihfkf2$fef$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
Krinkle wrote:
So PHP would extract {{#author:4}} and {{#license:12}} from the textblob when showing the editpage. And show the remaining wikitext in the <textarea> and the author/ license as seperate form elements. And upon saving, generate "{{#author:4}} {{#license:12}}\n" again and prepend to the textblob.
Double instances of these would be ignored (ie. stripped automatically since they're not re-inserted to the textblob upon saving). One small downside would be that if someone would edit the textarea manually to do stuff with author and license, the next edit would re-arrange them since they're extracted and re-insterted thus showing messy diffs. (not a major point as long as it's done independant from JavaScript, which it can be if done from core / php).
If that's what you meant, I think it is an interesting concept that should not be ignored, however personally I am not yet convinced this is the way to go. But when looking at the complete picture of up/down sides, this could be something to consider.
-- Krinkle
That's an alternative approach. I was thinking in accepting them only at the beginning of the page, but extracting from everywhere is also an alternative.
------------------------------
Message: 6 Date: Sun, 23 Jan 2011 00:38:53 +0000 From: Magnus Manske magnusmanske@googlemail.com Subject: Re: [Wikitech-l] File licensing information support To: Wikimedia developers wikitech-l@lists.wikimedia.org Message-ID: AANLkTimFfJs98FEAmJ6mhBbFJ25Z7jXo+sgvFLU4r-XF@mail.gmail.com Content-Type: text/plain; charset=UTF-8
On Sat, Jan 22, 2011 at 10:09 PM, Platonides Platonides@gmail.com wrote:
Krinkle wrote:
So PHP would extract {{#author:4}} and {{#license:12}} from the textblob when showing the editpage. And show the remaining wikitext in the <textarea> and the author/ license as seperate form elements. And upon saving, generate "{{#author:4}} {{#license:12}}\n" again and prepend to the textblob.
Double instances of these would be ignored (ie. stripped automatically since they're not re-inserted to the textblob upon saving). One small downside would be that if someone would edit the textarea manually to do stuff with author and license, the next edit would re-arrange them since they're extracted and re-insterted thus showing messy diffs. (not a major point as long as it's done independant from JavaScript, which it can be if done from core / php).
If that's what you meant, I think it is an interesting concept that should not be ignored, however personally I am not yet convinced this is the way to go. But when looking at the complete picture of up/down sides, this could be something to consider.
-- Krinkle
That's an alternative approach. I was thinking in accepting them only at the beginning of the page, but extracting from everywhere is also an alternative.
OK, my 2 cents:
I would be in favour of extracting data from the {{Information}} template via the parser, but we talked about this over a year ago at the Paris meeting, and it was deemed too complicated (black caching magick etc.), and noone has stepped forward to do anything along those line, so I guess it's dead and buried.
Things like {{#author:4}} seem to be a nice hack to Get Things Done (TM). As was mentioned before, the temptation is great to expand it into a generic triplet storage a la Semantic MediaWiki, but that would probably complicate things to an extend where nothing gets done, again.
But one thing comes to mind: If someone implements an abstraction layer ("4" to a specific author) anyway, it should be dead simple to use it for tags as well. Just allow multiple {{#tag}}s per page (as opposed to {{#author}}), done. The same code that will allow for editing author and license information centrally should make it possible to edit tag information, i18n for example, so the tag display could be in the current user language (with "en" fallback). Search for tags i18n-style could be possible as well, if the translation information is encoded machine-readable as well, e.g. as language links ([[de:Pferd]] on the [[Tag:Horse]] page).
It might be too much to try to activate all of that in the first round, but IMHO the code should keep the use as tags in mind; it would be dreadful to waste such an opportunity.
Cheers, Magnus
------------------------------
Message: 7 Date: Sun, 23 Jan 2011 00:45:29 +0000 From: Magnus Manske magnusmanske@googlemail.com Subject: Re: [Wikitech-l] WYSIFTW status To: Wikimedia developers wikitech-l@lists.wikimedia.org Message-ID: AANLkTikw+SCv3cUScc--1SvZE=54OgS=zydJUdwQpy=i@mail.gmail.com Content-Type: text/plain; charset=UTF-8
On Wed, Jan 19, 2011 at 10:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Wed, Jan 19, 2011 at 8:25 PM, Platonides Platonides@gmail.com wrote:
Magnus Manske wrote:
On my usual test article [[Paris]], the slowest section ("History") parses in ~5 sec (Firefox 3.6.13, MacBook Pro). Chrome 10 takes 2 seconds. I believe these will already be acceptable to average users; optimisation should improve that further.
Cheers, Magnus
What about long tables?
Worst-case-scenario I could find: http://en.wikipedia.org/wiki/Table_of_nuclides_(sorted_by_half-life)#Nuclide... s
4.7 sec in Chrome 10 on my iMac. 6.2 sec in Firefox 4 beta 9. 10.7 sec in Firefox 3.6.
Could be worse, I guess...
Another update that might be of interest (if not, tell me :-)
I just went through my first round of code optimisation. Parsing speed has improved considerably, especially for "older" browsers: Firefox 3.6 now parses [[Paris]] in 10 sec instead of 32 sec (YMMV).
Also, it is now loading the wikitext and the image information from the API in parallel, which reduces pre-parsing time.
For small and medium-size articles, editing in WYSIFTW mode now often loads (and parses) faster than the normal edit page takes to load (using Chrome 10).
Cheers, Magnus
------------------------------
Message: 8 Date: Sun, 23 Jan 2011 02:40:30 +0100 From: Maciej Jaros egil@wp.pl Subject: Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller! To: Wikimedia developers wikitech-l@lists.wikimedia.org Message-ID: 4D3B870E.2010407@wp.pl Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Michael Dale (2011-01-21 16:04):
On 01/21/2011 08:21 AM, Chad wrote:
While I happen to think the licensing issue is rather bogus and doesn't really affect us, I'm glad to see it resolved. It outperforms our current solution and keeps the same behavior. Plus as a bonus, the vertical line smushing is configurable so if we want to argue about \n a year from now, we can :)
Ideally we will be using closures by then and since it rewrites functions, variable names and sometimes collapses multi-line functionality, new line preservation will be a mute point. Furthermore, Google even has a nice add-on to firebug [1] for source code mapping. Making the dead horse even more dead.
I feel like we are suck back in time, arguing about optimising code that came out eons ago in net time ( more than 7 years ago ) There are more modern solutions that take into consideration these concerns and do a better job at it. ( ie not just a readable line but a pointer back to the line of source code that is of concern )
[1] http://code.google.com/closure/compiler/docs/inspector.html
Great. Now I only need to tell the user to install Firefox, install Firebug and some other addon, open the page in Firefox... Oh, wait. This error does not occur in Firefox...
Please, I can live with folding new lines (thou I don't believe those few bites are worth it) acutely compiling the code (or packing as some say) would be just evil for Mediawiki or Wikimedia to be more exact.
Just remember that people all over the world are hacking into Mediawiki all the time. Making it harder won't help a bit.
Regards, Nux.
------------------------------
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 90, Issue 48 ******************************************
wikitech-l@lists.wikimedia.org