wiki如何安装itween visual editoreditor
点击联系发帖人
时间：2015-09-05 19:34
| 时间排序
&a href=&http://www.gudianxue.org& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&www.gudianxue.org&i class=&icon-external&&&/i&&/a&
古典學百科
古典學百科
&a href=&http://www.gudianxue.org& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&www.gudianxue.org&i class=&icon-external&&&/i&&/a& 古典學百科
古典學百科
先问是不是，再问为什么&br&&a href=&http://zh.moegirl.org/Mainpage& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&萌娘百科 万物皆可萌的百科全书&i class=&icon-external&&&/i&&/a&
先问是不是，再问为什么
&ul&&li&&b&php&/b&。整套开源、自由版权的 MediaWiki 软件都是由 php 写的&br&&/li&&li&&b&python&/b&。维基百科里有一些执行大规模重复化工作的「机器人」账户——一个工作案例是把「钱钟书」批量替换为「钱锺书」——这些机器人实际上是预先编好的一段程序。除了 python 之外，还有 &b&.net&/b& 和 &b&perl &/b&编写的机器人 （&a href=&https://zh.wikipedia.org/?curid=10690#.E5.8F.AF.E5.B0.8D.E6.96.BC.E6.A9.9F.E6.A2.B0.E4.BA.BA.E6.9C.89.E7.94.A8.E7.9A.84.E8.BB.9F.E4.BB.B6& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&wikipedia.org 的页面&i class=&icon-external&&&/i&&/a&）&br&&/li&&li&&b&javascript&/b&。js 脚本可以在 MediaWiki 用户界面上补充出强大的额外功能，来辅助用户进行各种维护工作，比如对更改差异链接进行预览的 popups，巡查员喜闻乐见的 twinkle 等等。&br&&/li&&li&&b&lua&/b&。后来引进维基百科的，用于模板之中，具体可以参看 &a href=&https://zh.wikipedia.org/wiki/Wikipedia:Lua& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&zh.wikipedia.org/wiki/W&/span&&span class=&invisible&&ikipedia:Lua&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&/li&&/ul&暂时就想到这么多。学习的建议恕无法提供，因为我自己也不懂哈哈
php。整套开源、自由版权的 MediaWiki 软件都是由 php 写的python。维基百科里有一些执行大规模重复化工作的「机器人」账户——一个工作案例是把「钱钟书」批量替换为「钱锺书」——这些机器人实际上是预先编好的一段程序。除了 python 之外，还有 .net 和 …
在mediawiki和dukuwiki中纠结，由于用户需求，我用dukuwiki使用到了edittable这个插件很好用，但是它又不支持{{}}这种模板引用，mediawiki可以很好的用{{}}模板但是没找到edittable这种插件，做同一个网站不能同时使用，请问大神们，有没有解决方案？找了几天了~~
在mediawiki和dukuwiki中纠结，由于用户需求，我用dukuwiki使用到了edittable这个插件很好用，但是它又不支持{{}}这种模板引用，mediawiki可以很好的用{{}}模板但是没找到edittable这种插件，做同一个网站不能同时使用，请问大神们，有没有解决方案？找了几…
根目录一般都是api end。 如果api end 和/wiki/网页在同一个地址的话容易产生问题。比如用户定义一个页面叫做api?query。查询这个页面会跟api的接口冲突。
根目录一般都是api end。 如果api end 和/wiki/网页在同一个地址的话容易产生问题。比如用户定义一个页面叫做api?query。查询这个页面会跟api的接口冲突。
Gollum，Git+Markdown，最适合程序员的Wiki。
Gollum，Git+Markdown，最适合程序员的Wiki。
为安全起见，默认不允许删除用户，你可以在数据库里面删除。
为安全起见，默认不允许删除用户，你可以在数据库里面删除。
谢起名邀&br&这个问题我之前详细的分析过（&br&我先随便说几条（之前回答投资人的）&br&&ol&&li&用户基础的不成熟，我在另一个问题里面回答了一些，可以参考下：&a href=&/question//answer/& class=&internal&&维基百科的社群为何逐年缩小？ - 林家闻的回答&/a&
很多人压根就没听过wiki farm这种东西，我遇到不少朋友，我跟他说wikia，他就问，是维基百科吗？足可见这一模式几乎是无人知晓。还有就是国内互联网用户真是忙，喜欢快餐式的平台，（社会生活水平的问题，大部分的人都活动忙忙碌碌的不是么？）所以维基的东西对国内用户来说要求太高。简单来说就是需求不足，所以没人做。&/li&&li&Wikia进不来中国，这个问题很像为什么脸书推特进不来，因为被墙（移动上不去），被封锁（注册邀请码是google的），语言障碍（中文本地化程度太低）。我就不吐槽wikia了哈，用过的都知道。&/li&&li&wikia以及背后的这种wiki farm方式，还是以mediawiki为主，交互设计很geek，很多东西要靠代码来写，英语不是我们的母语，因此很多人尤其是兴趣社区人群并没有这么强的学习能力和接受能力，尤其是许多妹纸一看到代码就萌萌哒晕过去了……&/li&&li&国内特殊的平台环境，由于wikia没进来，于是目标用户都被百度（tieba）豆瓣、lofter、微博分流了。仅仅百度贴吧为例，一天就4亿+的PV。你想想这是一种市场已被瓜分完毕的假象，一般的投资者和创业者根本不敢涉足。&/li&&/ol&但是，其实不然。&br&我先简单说一些我对互联网产品以及wiki farm的个人见解。&br&&br&&b&任何一个互联网产品，他的产生都是为了迎合主流用户需求的，（有人做就意味着背后有人买单，呼声高了才会有人去投资，说白了大家都是为了逐利）否则都是耍流氓。比如&/b&&br&&ul&&li&人人是为了上同学（误）当有十万个学生想上同学的时候，renren出现了&/li&&li&微博是为了晒牛排和iphone，有一百万个人想低调晒xx的时候，微博出现了，&/li&&li&知乎是为了满足空虚寂寞冷装一把大神&a href=&/question//answer/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/question/2813&/span&&span class=&invisible&&3416/answer/&/span&&span class=&ellipsis&&&/span&&/a&&/li&&li&……那么同理&/li&&/ul&wikia（以及同样的wiki farm）是为了满足&b&谁&/b&的&b&什么&/b&需求而产生的呢？&br&首先wikia的用户，也就是“&b&谁&/b&”，就比较特殊，我把他的用户分成“生产者”和“消费者”，生产者就是编辑，消费者就是浏览者。和很多UCG不一样的是，wiki farm上的绝大多数内容是很小一部分人生产的。我举个简单的例子，冰与火之歌中文维基每天的pv在5~6万左右，但是编辑者不超过30个。&br&&ul&&li&wiki farm首先满足的是“生产者”（编辑）的生产需求。没有编辑就没有内容&/li&&li&wiki farm其次才满足了“消费者”（浏览者）的阅读需求。没有观众就不会赚钱&/li&&/ul&这个模式特别（或者说矛盾）的地方就在于，他的盈利模式相对滞后，赢利点主要取决于“消费者”，广告价是按照pv来收费的，没人看，自然卖不出去。 但是内容消费者是很惰性或者说随性的一个群体，绝大多数的人口味没那么挑剔，举个例子，一个marvel的漫迷，即使国内没有wikia，他可以去微博刷一刷#Avengers#，或者去mtime看一看时光专题，或者去豆瓣的comic小组瞅几眼，以及在贴吧、新闻都能获得一些零星的资讯（尽管可能是二手、不成体系的）。因此有着更高呼声和话语权的人群并没有不满，所以他们没有发声。&br&而真正有需求的那些“生产者”们——即核心的、骨灰级的geek粉丝，毕竟只是少数派，他们的呼声不足以产生质变，催生一个新的互联网产品。&br&所以在投资人和创业者眼里，这个需求是不存在的。&br&————————————————————————&br&但事实真是如此吗？我看未必&br&因为内容消费者，恰是互联网中最没有忠诚度可言的，一旦有了好的内容，他们分分钟跑给你看，大家都是为了更方便、耗时更少的看到更好更优质的内容，如果国内有一个Marvel Database，那么谁还会去看百度百科？&br&因此国内没有wikia这种专题型的自建wiki平台，原因有很多，最直接的就是大部分互联网创业者和资本的盲目短视造成的。市场还是存在的，需求也是存在的，混过贴吧豆瓣的都知道有爱的粉丝和群体是多么的有热情和创造力。&br&所以我认为只要解决了内容生产者的需求，即给他们一个一站式的Fansite解决方案，假以时日，我们也能孕育出本土的wiki farm品牌，从推特到微博，从quota到知乎都是如此。而且我认为wikia本身就问题多多，我们完全能够做出一个更好的平台。&br&——————————————————————&br&这么一个平台，从前没有，现在有一个，huiji.wiki（目前还在内测），我不打广告，有兴趣的朋友可以自己了解，自己判断：）&br&————————————————————————————————&br&P.S.可能有人会提到joyme，我并不想抹黑着迷，但是我认为他只是一个手游平台为了挽救用户，三心二意搞出的副业罢了，从骨子里就没有找到正确的方向和基因。所以我并不认为他是一个纯正的UGC wiki farm。
谢起名邀这个问题我之前详细的分析过（我先随便说几条（之前回答投资人的）用户基础的不成熟，我在另一个问题里面回答了一些，可以参考下： 很多人压根就没听过wiki farm这种东西，我遇到不少朋友，我跟他说wik…
建议题主把 自己 Wiki 的公网网址 发出来，大家别人可以从前端的角度 调试、诊断一下～
建议题主把 自己 Wiki 的公网网址 发出来，大家别人可以从前端的角度 调试、诊断一下～
网上有维基百科的mdx格式的数据包，2-3个g，用mdict可以打开，也可以用转换工具转换成文本
网上有维基百科的mdx格式的数据包，2-3个g，用mdict可以打开，也可以用转换工具转换成文本
来自子话题：
如同markdown的理念一样，所见及所得有时候会带来很多看不见却多余的HTML元素，维基百科注重的是内容，易编辑易阅读才是首要的。所见及所得未必是最易编辑的，熟悉了它的编辑器效率会很高。
如同markdown的理念一样，所见及所得有时候会带来很多看不见却多余的HTML元素，维基百科注重的是内容，易编辑易阅读才是首要的。所见及所得未必是最易编辑的，熟悉了它的编辑器效率会很高。
为了让作者能够专注撰写内容，而非费心于格式排版。同时，也让不同作者撰写的文章能有统一的格式与排版。&br&---------------------&br&当你开始认真思考、撰写文章的时候，只要敲字即可（甚至可以不用鼠标，像 Vi/Vim 是吗），保存文章的时候，“哗”的一下格式排版就完成了。这样的写作效率是非常高的。&br&当然，有些内容（如表格）还是有点复杂，所以 MediaWiki 提供了快速插入内容模板的简单功能。&br&我自己网站的内容编辑器也是类似理念，因为完全是自己开发的，深知这看上去简单粗糙的编辑器实现起来有多么复杂。
为了让作者能够专注撰写内容，而非费心于格式排版。同时，也让不同作者撰写的文章能有统一的格式与排版。---------------------当你开始认真思考、撰写文章的时候，只要敲字即可（甚至可以不用鼠标，像 Vi/Vim 是吗），保存文章的时候，“哗”的一下格式排…
我改词条都用可视化编辑器...不过也有缺点，比如我遇到的表格需要上下合并，我找了很久也找不到在哪儿...
我改词条都用可视化编辑器...不过也有缺点，比如我遇到的表格需要上下合并，我找了很久也找不到在哪儿...
来自子话题：
你要的VE：&br&&img src=&///6e1908145bdf99a053aebc_b.jpg& data-rawwidth=&1171& data-rawheight=&591& class=&origin_image zh-lightbox-thumb& width=&1171& data-original=&///6e1908145bdf99a053aebc_r.jpg&&记得用账号登陆才有。
你要的VE：记得用账号登陆才有。
维基媒体基金会正在开发可视化编辑器，称作&a class=& wrap external& href=&http://www.mediawiki.org/wiki/VE& target=&_blank& rel=&nofollow noreferrer&&VisualEditor&i class=&icon-external&&&/i&&/a&。&br&&br&MediaWiki标记语言是从2002年开始的，这十几年间，有什么feature的要求就加一个什么feature，结果是做成了一个非常庞大且复杂的标记系统，且可以说没有多少系统性可言，想实现它的功能只能一点点来做。同时作为一个&b&多语言程序&/b&，它要兼容所有的语言，为多种语言提供美式键盘下的输入能力，同时由于用户词库的原因又要兼容系统自带的输入法（最初曾一度做成捕捉键盘导致东亚几种语言无法使用），个别几种语言还要保证编辑结束后实现字词转换。更何况极为复杂的解析器函数、模板嵌套、高级CSS和表格用法等等能否实现都还是个未知数——必须强调：&b&MediaWiki系统的功能比起现有的所有主流网站的可视化编辑器都要庞杂&/b&。&br&&br&此外，MediaWiki的开发模式决定了不可能一次性搞定，也不可能在发布之前找一大堆人来debug，只能让志愿者充当debugger，边用边改，所以让可视化编辑投入使用的时候就完全实现标记语言的功能是不可能的。&br&&br&既然不能全部实现，那么现有的编辑器必须可以兼容可视化编辑和标记语言。因而VE需要&b&将编辑结果返回成标记语言储存&/b&，这也是VE最为困难的一点。VE刚推出试用的时候，甚至到了在可视化界面输入两对方括号（也就是最经典的标记符号[[链接]]）都无法做出任何合理处理的程度，实际上甚至几个月前还在解决类似这样的问题。&br&&br&综上所述，现在能登陆用户试用已经是很高的水平了。&br&我甚至一度不看好VE的前景。现在看他们大概是做出来一些了，但离应用还早。尤其是还有很多容易得多的新项目推进也极为缓慢，比如Flow。
维基媒体基金会正在开发可视化编辑器，称作。MediaWiki标记语言是从2002年开始的，这十几年间，有什么feature的要求就加一个什么feature，结果是做成了一个非常庞大且复杂的标记系统，且可以说没有多少系统性可言，想实现它的功能只能一点点来…
这是第二次回答自己提出的问题了，看来本人还是折腾摸索学入了门。&br&步骤：&br&（一）
搭建服务器环境&br&&p&简单的说就是：安装后找到程序根目录，找到www文件夹，复制wiki和wordpress文件。（网上好多人说的是放在一个更深的文件夹里，我不明白为什么）&/p&&blockquote&请参见&a href=&/freeyiyi1993/archive//3352387.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&windows下用wampServer 为wordpress 搭建本地服务器运行环境&i class=&icon-external&&&/i&&/a&&/blockquote&&p&（二）
从meidawiki（网络）到mediawiki（本机）&/p&&p&没想到mediawiki程序还挺开放的，根本不需要管理员权限就可以导出数据&/p&&p&“所有页面”——特殊:所有页面——导出数据——修改数据：通过notepad++的替换功能把日期改成最近几天，方便导出&/p&&blockquote&导出所有页面参见：&a href=&http://shanglei.net/hulianwang/mediawiki-export-backup.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&如何导出mediawiki的页面（用于内容备份或内容转移）&i class=&icon-external&&&/i&&/a&&/blockquote&&p&导入页面”从“特殊页面”进入，本地服务器有点脆弱，要导入N次才完毕。&/p&&p&（三）
从mediawiki（本机）到rss&/p&&p&为什么不直接从本站导出呢？因为本站导出rss有时间限制（最近N天更改），只能导出最近几天的词条。导入到本机后所有词条的作者都变成一个人了（记得替换用户名），时间也是最近几天。下面再次导出数据。导出rss很轻松：“最近修改”橙色按钮，保存即可。&/p&&p&（四）
从rss到wordpress&/p&&p&这一步简直是神坑！wordpress自带了个“rss”导入插件，然后导入之后全都是“All done. Have fun!”&/p&&blockquote&具体情况见&a href=&/question/& class=&internal&&通过 Google Reader 导出的.xml 文件，在wordpress 后台导入RSS，提示 All done. Have fun! ，但无数据导入，请问如何解决呢？
RSS链接见补充： - WordPress&/a&，这问题一直没人回答。&/blockquote&&p&然后就这样失败了N次之后…我明白了，这插件才1.4M，不靠谱，八成根本就没开发这功能。此时只需要换一个“feedwordpress”或“jps get rss feed”等类似插件即可&/p&&p&老外开发的东西就是不靠谱，不是要钱就是要折腾。有一个csstransport的网站可以直接把wiki生成wordpress网站，不过要100多美元……&/p&&br&&p&希望本文的读者不要拿这个作死复制别人网站的内容，否则我就是wiki界的罪人了…本来想回答“不要回答！”的…当然这个方法也引出了俩新的问题：&/p&&ol&&li&如何防止自己百科网站的内容被复制？&/li&&li&如何顺便导出单个词条链接而不是内链？&/li&&/ol&&p&希望有大牛解答！&/p&
这是第二次回答自己提出的问题了，看来本人还是折腾摸索学入了门。步骤：（一） 搭建服务器环境简单的说就是：安装后找到程序根目录，找到www文件夹，复制wiki和wordpress文件。（网上好多人说的是放在一个更深的文件夹里，我不明白为什么）请参见From MediaWiki.org
&translate&
This MediaWiki page is inactive and kept for historical interest.&/translate& &translate& It may document extensions or features that are obsolete and/or no longer supported.&/translate& &translate&
Do not rely on the information here being up-to-date.&/translate&
This page contains updates on the
project that were made between May 2011 and December 2014. It is no longer updated. For current news about the project's progress, see the
from the Editing team (, ) and before that VisualEditor (, , , ). For current information about VisualEditor's roadmap, see the .
have done exploratory work on the visual editor project. Neil
(a custom version of Etherpad, a real-time collaborative editing software) on a proof of concept of integration between Etherpad and MediaWiki (). They're now working on turning it into a MediaWiki extension. Work on the visual editor is also intersecting with the groundwork done on the new parser.
have done exploratory work on the visual editor project. Neil
(a custom version of real-time collaborative editing software Etherpad) on a proof of concept to integrate Etherpad and MediaWiki (). They're now working on turning it into a MediaWiki extension. Trevor continues to work on WikiDom, a storage structure and functionality acting as an intermediate layer between the parser and a visual editor. This work also intersects with the groundwork done on the new parser.
continued to work on the front-end of the visual editor, and specifications for accessing the editing surface via the API. A hybrid rendering approach appears to be the best strategy for the visual editor.
continued to work on the middleware, DOM and transactions. Neil also continued to work on a demo to integrate MediaWiki and . With , they planned their upcoming sprints. Neil and Trevor are posting about their work to .
continued to work on the front-end of the visual editor and he was joined by , a developer from Wikia, who are also interested in the visual editor.
worked on , concurrent editing and dived into the inner workings of Etherpad. (.)
worked on a transaction-based model for the visual editor, where the document is built as a series of events (instead of saving it entirely at every change), which makes it easier to undo actions.
continued to work on
and is close to presenting a demo of Etherpad working inside a MediaWiki edit window.
investigated and started to work on a chat system to be integrated to the concurrent editing interface, for collaboration and live help. More details .
expanded the . He also refactored some of the data structures to follow a model/view controller pattern and support document-level transactions. He wrote tests for the new structure, and got it to render
he's now working on rendering tables.
worked on a new model tree (and the conversion from the linear model) and updated the .
worked on front-end functionality: dialogs, selecting text, mouse actions, scrolling, keyboard shortcuts, etc.
focused on algorithms that insert ranges of data into a document, and
on the removal of data. On the parser side, a basic parser using PEG is in place, which produces an intermediate JSON
is still working on markup support (mixed HTML and Wikitext).
joined the team and started to work on the PEG parser ().
fixed issues blocking the synchronization of structural edits to the user interface, refactored and cleaned up the code, and mapped out
and . He also finished the document transaction functionality and made progress on an undo/redo system.
added tests, rewrote some code to make the tests pass, and fixed a number of bugs and issues, notably in Internet Explorer.
continued to work on content insertion, deletion and selection and fixed numerous bugs.
extended the
for robust larger-scale parsing. He converted the PEG parser into a combined wiki and HTML tokenizer that feeds to a HTML5 DOM tree builder. He implemented several wikitext features (lists, italics, bold) as token stream transformations. 139 of about 660 parser tests are now passing.
The first public developer prototype of the visual editor sandbox was deployed to MediaWiki.org for public feedback and testing. It can be accessed via the
special page.
in the Wikimedia blog.
The team deployed a developer prototype of the
to mediawiki.org for public feedback and testing.
fixed bugs and refactored code.
worked on the toolbar (text styles), the undo/redo stack, and lists (creating, deleting, and changing indentation).
worked on the parser test runner and the , including
and template expansions.
worked on the undo/redo feature and did a lot of refactoring.
January was a bit slower on the visual editor front, as parts of the team took some well-deserved vacation after the successful
in December. During the SF Hackathon, a lot of issues were fleshed out.
were formulated.
investigated a possible use of contenteditable to help with input methods and text selections on mobile devices.
with the ability to fetch and expand templates in a parallel and asynchronous fashion. The parser now supports most parts of the .
did research on cursor interaction and selection rendering for RTL (right-to-left) and support for line breaks in PRE elements.
improved template expansion and parser function support, investigated Microdata and RDFa for WikiText-in-HTML-DOM embedding and added rough support for images and other files.
committed a working Editable Surface IME prototype (bidirectional text not fully supported).
joined the team and worked on the sanitizer and the testing process.
Exploration of using ContentEditiable (CE) in place of EditSurface (ES) for the display layer was successful, and the team is integrating the new display layer system into the rest of the codebase. Inez and Christian are continuing their work on CE while Rob is focusing on getting the UserInterface (UI) module working with CE. Rob will be refactoring UI and adding an API layer for toolbar and inspector extensions. Trevor and Roan are focusing on DataModel (DM) changes that need to be done to improve tree sync and integration with the parser (Parsoid). Gabriel and Audrey are continuing their work on Parsoid.
Last week made big decisions. The big one was to move forward with contentEditable (CE) that Inez and Christian are doing in place of Editable Surface (ES). Looks like editing on mobile will be awesome!
will be focusing on the data model (DM. DOM -& Linear Parser) as the basic objectives have been hashed out, the (parser -& DM is unaffected). Certain structure changes (i.e. turning paragraphs to lists) aren't currently possible so the DM will change to support that. Linking with the parser (DOM-& LM converter) will be deferred for a week.
In terms of the UI,
worked on some RTL in ES, but switched given the CE advances. This week will focus on getting the UI working in CE (assess what UI we have from ES and where it needs to be). Plan on getting to the point we can user test the JS API for the toolbar.
In terms of the parser,
has to decide on RDFa vs. microdata eventually (difference are minimal, most of the DOM stuff won't change and can be tested with vanilla HTML anyway). Created a dump grepper with syntax highlighting and used that to analyze existing wikilink/image syntax use. Refactored tokenization and expansion of wikilink/images so now image options can come from templates (257 tests passing now). Plan on tackling interacting with action=parse and wiki in general. Also some more parser function tweaking, etc. and the RDFa/microdata decision.
Team updated (sans key people who are out of commission): . Further updates/corrections by Trevor and Gabriel expected when they return.
A big decision in March was to move forward with contentEditable (CE), implemented by Wikia developers
and Christian Williams, instead of Editable Surface (ES).
focused on the data model.
worked on the user interface, first on right-to-left support in ES, then on getting the UI working in CE.
continued their work on
and need to decide on RDFa vs. microdata. They created a dump grepper with syntax highlighting, and used it to analyze existing wikilink/image syntax use.
are rewriting the underlying data model (ve.dm) to achieve feature compatibility with the parser and correct a variety of problems that have been previously deferred.
and Christian Williams have been continuing their work to stabilize and integrate the content editable layer (ve.ce) and have been working with , who has focused on getting the user interface elements working with the content editable layer (ve.ui).
has been working on improving the 's ability to parse pages more quickly as well as increasing compatibility with existing features such as thumbnails. A big template-heavy page like
can now be expanded in similar time as the production parser (80 seconds on a puny laptop) and 340MB of memory. It previously ran out of memory after consuming 1.6G and running for ~30 minutes.
BY JUNE! 5 weeks.
What we want:
parse page
load editor
save it back
not hard to load simple pages
but not roundtripping it (because not all tags are supported)
Serializaiton: some normalization. focusing efforts on reconcilliation instead?
For Roundtripping: Need more support. Handle templates (started by one and ended by another), also template parameters. (linear model supports both: but data model only allows edit templates parameters on opening).
Just finished Refactoring so it can expand big articles. A few more days left of followup.
Serializer:
"Alien Nodes" (HTML we don't understand)
acknowledge that dirty diffs will happen.
Have a sandbox deploy, create a namespace for it.
Roundtrip something!
Probably a namespace limit, sandbox
allow dirty diffs or disallow manual editing and start from scratch.
If source editing, then it will run it through the parser as a presave transformation. Warning banner with X? so may not have source mode editing only if developer mode.
Maybe Gabriel can refocus on serialization (worried abotu stuff that will be shifting).
get it ready incremental improvements on front-end, but on the serialization and back-end that will change.
James Forrester:
sooner is better. :-)
He will need to be on board for the release in (late) June
Things to be done for release:
Gabriel needs to refocus on serialization (for roundtripping) after he gets the refactor settled (next couple days)
Finish DM rewrite stuff. As soon as it is in master then we start doing integration.
This week: Get feature completeness with transactions]
On FE, rework observation stuff, toolbar into the DM stuff as it comes along.
Annotation should be working today.
Integration work?
MW integration [Roan]
FE integration- do a "ooh and ahh" it.
Node.js integration [Gabriel will get working, and Roan will puppetize and give to Ops]. Roan has Node.js installed on a VM project.
Release Notes: Dec to June (reason)
Switch from ES to CE (due to CE, This warrants a blog post)
Mobile editing support (due to CE, Patrick can hack up something)
February stuff: Supports spellcheck, autocorrect, IME (due to CE)
turn headline into paragraph
feature parity w/ previous demo (internal check)
Load and save (parser/serializer, backend integration)
In-place editing (frontend integration)
Graceful failure/fallback (AlienNode)
[TBD] partial iage support (DM rewrite)
Trevor will make a task list in-wiki. If it doesn't work out, will consider to switching to .
Tracking ongoing work:
Gabriel has set up a very basic .
browse english wikipedia as parsoid sees it
POST wikitext -& HTML DOM
POST HTML DOM -& wikitext.
Note: round-tripping is limited. Does not support preservation of variable whitespace, templates and other complex constructs yet.
Currently 154 parser tests are passing in the new --roundtrip mode that Subbu added last week.
The team completed
for June and welcomed
as the Technical Product Analyst for the project. Ongoing work on the
is tracked on-wiki.
set up a very basic
that lets users browse the English Wikipedia as Parsoid sees it, and convert Wikitext to HTML DOM and vice versa.
The team did the , with an early version now live in a test namespace on mediawiki.org. This editor is broadly feature-compatible with the old, EditableSurface-style code which this replaces, while being the first release that can create and edit pages. The team is now planning to deploy new code as it develops every two weeks or so. The initial push will be to work on bug-fixes, and to finalise the code for a few features that were close to being ready before the first deployment.
The VisualEditor (VE) team presented their work at Wikimania and received a good deal of feedback from the community. The team created . The early version of VE on mediawiki.org was updated twice, fixing a number of bugs and noticeably including the addition of support for nested lists. Gabriel Wicke relocated to San Francisco, and Timo Tijhof visited the SF office for three weeks after Wikimania.
In August, the team focused on overhauling the code design of VisualEditor so that it is more modular and easier to extend. This involves creating and documenting a number of formal APIs at each point in the architecture, that means a developer does not have to understand the entire code base to be able to add new features. The early version of the VisualEditor on mediawiki.org was updated twice ( and ), fixing a number of bugs, as well as adding a much-improved link inspector to help users build links, and a save dialog that better guides users on what to do.
In September, the team continued its focus on re-engineering the code design of VisualEditor so that it is more modular and easier to extend. This involves creating and documenting a number of formal APIs at each point in the architecture, that means a developer does not have to understand the entire code base to be able to add new features. The early version of the VisualEditor on mediawiki.org was updated twice ( and ), fixing a number of bugs and building out better support for internationalisation and key concepts like categories, language links and other "magic words".
In October, the team worked to finish most of the re-engineering the code design of VisualEditor so that it is more modular and easier to extend. This has involved creating and documenting a number of formal APIs at each point in the architecture, so a developer does not have to understand the entire code base to be able to add new features. The early version of the VisualEditor on mediawiki.org was updated three times (,
and ), fixing a number of bugs and replacing the entire browser selection and typing models, and much of how the user interface connects with the rest of the code.
In November, the team worked primarily on finalizing the code re-engineering of VisualEditor so that it is more modular and easier to extend, and on the integration ahead of deploying it for wider testing in December. The early version of the VisualEditor on mediawiki.org was updated twice ( and ), fixing a number of bugs and missing wikitext compatibility, and wide-spread improvements to much of the user interface code so that it will be easier to change in future.
In December, the team
an alpha version of the VisualEditor for editors to use and give feedback on issues and priorities. The team's work focussed on ensuring that the integration was reliable, and providing a dedicated tool for editors to report problems with editing, and, after deployment, addressing the reports and ideas from editors. The early version of the VisualEditor on mediawiki.org was also updated to use the new developments (as part of ).
In January, the team worked primarily on reviewing and cleaning-up the code
in December. They spent time with their colleagues in the Parsoid team planning the next phase of development, which is aimed at making the VisualEditor the default editor for all Wikipedias from July 2013. The alpha version of the VisualEditor on mediawiki.org and the English Wikipedia was updated twice ( and ), fixing a number of bugs reported by the community and making some adjustments to the link inspector's functionality based on feedback.
In February, the team worked on improving the design, user interface components and API infrastructure of VisualEditor, preparing for the new features that will be added in the coming months. The objective is for VisualEditor to be the default editor for all users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. This will mean adding support for references, (at least) basic templates, categories and images, each of which is a very large piece of work. During this time, the team has expanded with the recruitment of , who will focus on the data infrastructure of VisualEditor's platform. The alpha version of VisualEditor on mediawiki.org and the English Wikipedia was updated twice ( and ), adding support for Microsoft Internet Explorer (version 9 and above), fixing a number of bugs reported by the community, improving internationalisation, and restructuring the data model layer so that the code interfaces are ready for the new features.
In March, the team worked on the major new features that will be added in the coming months. The objective is for VisualEditor to be the default editor for all users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. This will mean adding support for references, (at least) basic templates, categories and images, each of which is a very large piece of work. This month the primary focus was editing of categories and templates, with draft designs created and initial code developed. The team undertook its first ever "", whose
detail these designs, the work done to date and expectations for the near future. The alpha version of VisualEditor on mediawiki.org and the English Wikipedia was updated twice ( and ), adding better input and selection support, fixing a number of bugs, and restructuring the back-end so that the new features will be simpler to create.
In April, the team continued their work on the major new features that will be added in the coming months. Our objective is for VisualEditor to be the default editor for all Wikipedia users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. This means we have been focussed on four substantial areas of work: adding support for references, templates, categories and media items. During this time the main area of our work was editing around images, which is now designed and partially implemented in our experimental code, and around categories, which is almost complete and nearly ready for deployment. The deployed alpha version of VisualEditor was updated thrice (,
and ), adding speed improvements, user interface improvements and work on the back-end to better support the new features, and fixing a number of bugs. We also were able to
(and, later, Vietnamese Wikipedia too), which has let the community give us feedback on what works and is broken, and identifying language- and locale-specific issues we are now fixing.
In May, the VisualEditor team worked to complete the major new features we have prioritised over the past few months. Our objective is for VisualEditor to be the default editor for all Wikipedia users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. We have focussed on four areas of new functionality: adding and editing inclusions of references, templates, categories and media items. Our main area of work over the past month has been on references and templates, and we now have implemented editing them in o category editing is nearly complete and should be made available very soon. The deployed alpha version of VisualEditor was updated twice ( and ), adding a number of user interface improvements, including further work on the back-end to better support the new features, and fixing a number of bugs.
In June, the VisualEditor team completed the major new features that we prioritised over the past few months, in preparation for making VisualEditor available to most Wikipedia users in July. We have built an editor that is capable of letting users edit the majority of content without needing to use wikitext — text support, as well as adding and editing inclusions of references, templates, categories and media items. The deployed alpha of VisualEditor was updated four times as part of the transition to weekly deployments (, ,
and ), with several mid-deployment releases as the code was developed to patch urgent issues. Part of this involved running an A/B test for new user accounts on the English Wikipedia, with half of the users getting opt-in to VisualEditor ahead of the wider release. Generally, there were a number of user interface improvements, and fixing a number of bugs uncovered by the community.
In July, the VisualEditor team began switching the deployment from opt-in alpha to opt-out beta, so becoming the default editor for users of the various Wikipedias. The deployed version of the code was updated three times (,
and ), with several mid-deployment releases as the code was developed to patch urgent issues. There were a number of user interface improvements, most notably to the references insertion dialog, alongside fixes to a number of bugs uncovered by the community.
In August, the VisualEditor team continued work, and presented and ran workshops at
to discuss how to best improve the system. The deployed version of the code was updated three times (,
and ), with several mid-deployment releases as the code was developed to patch urgent issues. The focus in this work was in improving the stability and performance of the system, fixing a number of bugs uncovered by the community, and making some usability improvements.
In September, the VisualEditor team continued their work to improve the editor and roll it out to additional wikis. The deployed version of the code was updated four times (,
and ). The focus in the team's work this month was to continue to improve the stability and performance of the system, fix a number of bugs uncovered by the community, and make some usability improvements.
In October, the VisualEditor team continued to improve the stability and performance of the system, and add new features. The deployed version of the code was updated five times (, , ,
and ). Beyond fixing bugs, the focus of the team's work this month was to make a number of large structural changes to make the system more dependable and extensible, and continue to make some usability improvements. For example, you now need to press the "delete" key twice to delete a template, the first time, they only become selected, to avoid accidental deletion of infoboxes and similar content. A new feature, empowering users to switch from editing in VisualEditor to editing wikitext directly without having to save the page, was also implemented.
Presentation slides from the
on 7 November.
In November, the VisualEditor team continued to improve the stability and performance of the system, and add new features. The deployed version of the code was updated three times (,
and ). Most of the team's focus was on fixing bugs, and on some major infrastructure changes, splitting out the
libraries from VisualEditor to make them available to other teams. Much of the team travelled to the
in Pune, India to learn more about how to improve VisualEditor for a variety of languages, scripts, users and systems. Two new members of the
joined in to help improve VisualEditor –
and , and thanks to them, the automated browser tests have expanded in breadth and depth of coverage. Work continued on major new features like full rich copy-and-paste from external sources, a dialog for quickly adding citation templated references, and a tool to insert characters not available on users' keyboards. The editor was made available by default on just over 100 additional Wikipedias as part of the continuing roll-out. VisualEditor was also enabled for opt-in testing on Swedish Wiktionary and Wikimedia Sweden's wiki, the first time it has been available on a non-Wikipedia production wiki.
In December, the VisualEditor team worked to continue the improvements to the stability and performance of the system, and to add new features. The deployed version of the code was updated three times (,
and ). Most of the team's focus was on major new features and fixing bugs. There is now basic support for rich copy-and-paste from external sources into VisualEditor, and a basic tool to insert characters not available on users' keyboards. Work also continued on a dialog for quickly adding citation templated references, and on some major infrastructure changes, splitting out the core of VisualEditor from the MediaWiki-specific items like the transclusion editor.
In January, the VisualEditor team continued their work on improving the stability and performance of the system, and added some new features. Most of the team's focus was on major new features and fixing bugs. You can now edit some page settings like whether to display a table of contents or whether to show section edit labels, set the size of a media file manually, see a keyboard shortcuts help screen, and create and edit media galleries using a very basic stand-in editor whilst the final form is being designed. Work also continued on a dialog for quickly adding "citation" references based on templates, more media and page settings, setting content language and right-to-left flags, and equation editing. The deployed version of the code was updated four times (, ,
In February, the VisualEditor team continued their work on improving the stability and performance of the system, and added some new features and simplifications. Media item editing is now much richer, allowing the setting of position, alt text, size (or setting as default size) and type for most kinds of media item. When adding links, redirects and disambiguation pages are now highlighted to help editors select the right link, and changing the format or style of some text was tweaked to make editing clearer and more obvious. Adding and editing template usages is now a little smoother, auto-focussing on parameters and making them clearer to use. Page settings have expanded to set redirects, page indexing and new section edit link options. The extensive work to make insertion of "citation" references based on templates quick, obvious and simple neared completion. The deployed version of the code was updated four times in the regular releases (, ,
Presentation slides from the
on 26 March.
In March, the VisualEditor team continued their work on improving the stability and performance of the system, and added some new features and simplifications, helping users edit and create pages more swiftly and easily. Editing templates is now much simpler, moving most of the advanced controls that users don't often need into a special version of that dialog. The media dialog was improved and stream-lined a little, adding some hinting to the controls to explain how they work a bit more. The cursor entry points inserted by VisualEditor next to items like images or templates to give users somewhere to put the cursor now animate on hover and cursor entry to show that they're special. The overall design of dialogs and controls was improved a little to make it flow better, like double-clicking a block to open its dialog. A new system for quickly and simply inserting and editing "citations" (references based on templates) neared completion and will be deployed in the coming month. The deployed version of the code was updated four times in the regular releases (, ,
In April, the VisualEditor team worked to improve the stability of the editor, adding some new features and improving usability so that users can create and edit pages more swiftly and intuitively with VisualEditor than before. Template editing was over-hauled to make adding parameters less busy, showing only a few parameters at first rather than all possible ones, which can number in the dozens or more, especially in the case of some often-used templates like those for citations or infoboxes. Setting the size of images was tweaked to give a more natural set of controls based on feedback from users. The page settings dialog had a number of minor tweaks, leading to the set of options that can be modified inside VisualEditor being completed. VisualEditor's edit tab is now more consistent with the rest of the MediaWiki interface in a number of noticeable if minor ways, such as on pages to do with the Education Program, on file pages which are hosted on Commons rather than on the local wiki, or on very narrow screens. User testing was carried out on the forthcoming citation dialog and some final simplifications were made, such as adding suggested as well as required parameters, ahead of its pending introduction. Finally, a careful audit of all Wikimedia wikis led to fixing broken local community-written code, to ensure that VisualEditor runs on all of them. The deployed version of the code was updated four times in the regular release cycle (, ,
In May, the VisualEditor team worked on the performance stability of the editor, rolled out a major new feature to help users better edit articles, and made some improvements to other features to increase their ease of use and understandability, fixing . The new citation editor is now available to all VisualEditor users on the English, Polish, and Czech Wikipedias, with
on how to enable it on other wikis. The citation and template dialogs were simplified to avoid technical language and some outcomes that were unexpected for users. As part of this, the citation icons were replaced with a new, clearer set, and the template hinting system now lets wikis mark template parameters as "suggested", as a step below the existing "required" state. The
is now available to all VisualEditor users, and a new Beta Feature giving a tool that lets you
was made available for testing and feedback. Following a new set of user testing, the toolbar was tweaked, moving the list and indent buttons to a drop-down to make them less prominent, and removing the gallery button which is rarely used and confused users. The mobile version of VisualEditor, currently available for alpha testers, was expanded to also have the new citation editor available, and had some significant performance improvements made, especially for long or complex pages. Work continued on making VisualEditor more performant and reliable, and key tasks like keyboard accessibility have progressed. The deployed version of the code was updated five times in the regular release cycle (, , ,
In June, the VisualEditor team provided a new way to see the context of links and other items when you edit to make this easier, worked on the performance and stability of the editor so that users could more swiftly and reliably make changes to articles, and made some improvements to features focussed on increasing their simplicity and understandability, fixing . The editor now shows with a highlight where dragging-and-dropping content will put it, and works for any content, not just for images. The citation and reference tools had some minor adjustments to guide the user on how they operate, based on feedback and user testing. A lot of fixes to issues with windows opening and closing, and especially the link editing tool, were made, alongside the save dialog, categories, the language editing tool, table styling, template display and highlights on selected items. The mobile version of VisualEditor, currently available for alpha testers, moved towards release, fixing a number of bugs and improving performance. Work to support languages made some significant gains, and work to support Internet Explorer continued. The new visual interface for writing TemplateData was enabled on the Catalan and Hebrew Wikipedias. The deployed version of the code was updated four times in the regular release cycle (, ,
In July, the team working on VisualEditor converged the design for mobile and desktop, made it possible to see and edit HTML comments, improved access to re-using citations, and fixed .
The new design, with controls focussed at the top of each window in consistent positions, was made possible due to the significant progress made in cross-platform support in the UI library, which now provides responsively-sized windows that can work on desktop, tablet and phone with the same code. HTML comments are occasionally used on a few articles to alert editors to contentious or problematic issues without disrupting articles as they are read, so making them prominently visible avoids editors accidentally stepping over expected limits. Re-using citations is now provided with its simple dialog available in the toolbar so that it is easier for users to find.
Other improvements include an array of performance fixes targeted at helping mobile users especially, fixing a number of minor instances where VisualEditor would corrupt the page, and installing better monitoring of corruptions if they occur, and better support for right-to-left languages, displaying icons with the right orientation based on context.
The mobile version of VisualEditor, currently available for beta testers, moved towards stable release, fixing a number of bugs and editing issues and improving loading performance. Our work to support languages made some significant gains, nearing the completion of a major task to support IME users, and the work to support Internet Explorer uncovered some more issues as well as fixes. The deployed version of the code was updated five times in the regular release cycle (, , ,
In wider news, the team expanded its scope to cover all MediaWiki editing tools as well, as the new Editing Team (covered below).
In August, the team working on VisualEditor presented about VisualEditor at , worked with a number of volunteers at the hackathon, adjusted key workflows for template and citation editing, made major progress on Internet Explorer support, and fixed .
Users of Internet Explorer 11, who we were previously preventing from using VisualEditor due to some major bugs, will now be able to use VisualEditor. Support for earlier versions of Internet Explorer will be coming shortly. Similarly, tablet users browsing the site's mobile mode now have the option of using a mobile-specific form of VisualEditor. More editing tools, and availability of VisualEditor on phones, is planned for the future.
Improvements and updates were made to a number of interface messages as part of our work with translators to improve the software for all users, and VisualEditor and MediaWiki were improved to support highlighting links to disambiguation pages where a wiki or user wishes to do so. Several performance improvements were made, especially to the system around re-using references and reference lists. We tweaked the link editor's behaviour based on feedback from users and . The deployed version of the code was updated three times in the regular release cycle (,
In September, the team working on VisualEditor expanded browser support, improved some features, and fixed .
Users of Internet Explorer 10, who we were previously preventing from using VisualEditor due to some major bugs, will now be able to use VisualE this follows on from Internet Explorer 11 support last month. When editing a template with a required field, VisualEditor now warns you to avoid leaving it blank, and you can now create auto-numbered links using VisualEditor.
Improvements and updates were made to a number of interface messages as part of our work with translators to improve the software for all users, based on feedback from users and . We made progress on table structure editing and auto-filled citations, both of which will be coming soon.
The deployed version of the code was updated five times in the regular release cycle ( , ,
In October, the team working on VisualEditor improved some features, prepared the way for table structure editing, and fixed .
The keyboard shortcuts for items in the toolbar's menus now show on the right hand side, to make them easier to find. We made a few improvements to the display and editing of templates. Firstly, template fields can now have a value automatically set, like today's date for clean-up notices. Links inside templates now show in red if their targets don't exist, like for the editing surface. Last month's change to warn against saving a template with missing required fields was improved by highlighting them, as is the warning about trying to make an image 0 pixels wide.
The initial tools to edit the structure of tables were finalised and will be made available next month. We made progress on providing a new
tool, and improvements to the
tools, all of which will be coming in the near future.
The deployed version of the code was updated five times in the regular release cycle (, ,
In November, the team working on VisualEditor introduced table structure editing, improved some existing features, and fixed .
You can now edit the structure of a table, adding or deleting rows and columns and various other common tasks like merging cells and using captions. VisualEditor now support keyboard shortcuts like entering "* " at the start of a line t if you didn't mean to use the "smart" sequence, pressing undo will get back to what you typed. Most wikis now have VisualEditor available as an opt-in tool, whereas previously communities had to ask for it to be switched on.
The toolbar's menus in VisualEditor now open in a collapsed, short form with uncommon tools only shown when requested. You can now create and edit simple "blockquoted" paragraphs for indenting. You can now use a basic editor for gallery and hieroglyphic blocks on the page. Category editing was enhanced in a few ways, including adding a redirect category now adds its target, and making categories without a description page show as red. We improved compatibility with some variations of how wikis use the Flagged Revisions system. Armenian language users now get customised bold and italic
if your language would benefit from customised icons, please .
We also made progress on providing a new
tool, and improvements to the
tools, all of which will be coming in the near future.
The deployed version of the code was updated four times in the regular release cycle (, ,
In December, the team working on VisualEditor introduced a new design for the front-end system that VisualEditor uses, improved several existing features, and fixed .
The new design of the interface is based on the future path set by the , and is intended to gel with designs across Wikimedia's tools and services and the wider direction of travel for the Web as a whole. The interface is subject to revision and improvements, and not feedback is appreciated from users and designers alike.
We also made a number of improvements to language editing and browser stability, progress on providing a new
tool, and improvements to the
tools, all of which will be coming in the near future.
The deployed version of the code was updated three times in the regular release cycle (,}
&a href=&http://www.gudianxue.org& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&www.gudianxue.org&i class=&icon-external&&&/i&&/a&
古典學百科
古典學百科
&a href=&http://www.gudianxue.org& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&www.gudianxue.org&i class=&icon-external&&&/i&&/a& 古典學百科
古典學百科
先问是不是，再问为什么&br&&a href=&http://zh.moegirl.org/Mainpage& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&萌娘百科 万物皆可萌的百科全书&i class=&icon-external&&&/i&&/a&
先问是不是，再问为什么
&ul&&li&&b&php&/b&。整套开源、自由版权的 MediaWiki 软件都是由 php 写的&br&&/li&&li&&b&python&/b&。维基百科里有一些执行大规模重复化工作的「机器人」账户——一个工作案例是把「钱钟书」批量替换为「钱锺书」——这些机器人实际上是预先编好的一段程序。除了 python 之外，还有 &b&.net&/b& 和 &b&perl &/b&编写的机器人 （&a href=&https://zh.wikipedia.org/?curid=10690#.E5.8F.AF.E5.B0.8D.E6.96.BC.E6.A9.9F.E6.A2.B0.E4.BA.BA.E6.9C.89.E7.94.A8.E7.9A.84.E8.BB.9F.E4.BB.B6& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&wikipedia.org 的页面&i class=&icon-external&&&/i&&/a&）&br&&/li&&li&&b&javascript&/b&。js 脚本可以在 MediaWiki 用户界面上补充出强大的额外功能，来辅助用户进行各种维护工作，比如对更改差异链接进行预览的 popups，巡查员喜闻乐见的 twinkle 等等。&br&&/li&&li&&b&lua&/b&。后来引进维基百科的，用于模板之中，具体可以参看 &a href=&https://zh.wikipedia.org/wiki/Wikipedia:Lua& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&zh.wikipedia.org/wiki/W&/span&&span class=&invisible&&ikipedia:Lua&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&/li&&/ul&暂时就想到这么多。学习的建议恕无法提供，因为我自己也不懂哈哈
php。整套开源、自由版权的 MediaWiki 软件都是由 php 写的python。维基百科里有一些执行大规模重复化工作的「机器人」账户——一个工作案例是把「钱钟书」批量替换为「钱锺书」——这些机器人实际上是预先编好的一段程序。除了 python 之外，还有 .net 和 …
在mediawiki和dukuwiki中纠结，由于用户需求，我用dukuwiki使用到了edittable这个插件很好用，但是它又不支持{{}}这种模板引用，mediawiki可以很好的用{{}}模板但是没找到edittable这种插件，做同一个网站不能同时使用，请问大神们，有没有解决方案？找了几天了~~
在mediawiki和dukuwiki中纠结，由于用户需求，我用dukuwiki使用到了edittable这个插件很好用，但是它又不支持{{}}这种模板引用，mediawiki可以很好的用{{}}模板但是没找到edittable这种插件，做同一个网站不能同时使用，请问大神们，有没有解决方案？找了几…
根目录一般都是api end。 如果api end 和/wiki/网页在同一个地址的话容易产生问题。比如用户定义一个页面叫做api?query。查询这个页面会跟api的接口冲突。
根目录一般都是api end。 如果api end 和/wiki/网页在同一个地址的话容易产生问题。比如用户定义一个页面叫做api?query。查询这个页面会跟api的接口冲突。
Gollum，Git+Markdown，最适合程序员的Wiki。
Gollum，Git+Markdown，最适合程序员的Wiki。
为安全起见，默认不允许删除用户，你可以在数据库里面删除。
为安全起见，默认不允许删除用户，你可以在数据库里面删除。
谢起名邀&br&这个问题我之前详细的分析过（&br&我先随便说几条（之前回答投资人的）&br&&ol&&li&用户基础的不成熟，我在另一个问题里面回答了一些，可以参考下：&a href=&/question//answer/& class=&internal&&维基百科的社群为何逐年缩小？ - 林家闻的回答&/a&
很多人压根就没听过wiki farm这种东西，我遇到不少朋友，我跟他说wikia，他就问，是维基百科吗？足可见这一模式几乎是无人知晓。还有就是国内互联网用户真是忙，喜欢快餐式的平台，（社会生活水平的问题，大部分的人都活动忙忙碌碌的不是么？）所以维基的东西对国内用户来说要求太高。简单来说就是需求不足，所以没人做。&/li&&li&Wikia进不来中国，这个问题很像为什么脸书推特进不来，因为被墙（移动上不去），被封锁（注册邀请码是google的），语言障碍（中文本地化程度太低）。我就不吐槽wikia了哈，用过的都知道。&/li&&li&wikia以及背后的这种wiki farm方式，还是以mediawiki为主，交互设计很geek，很多东西要靠代码来写，英语不是我们的母语，因此很多人尤其是兴趣社区人群并没有这么强的学习能力和接受能力，尤其是许多妹纸一看到代码就萌萌哒晕过去了……&/li&&li&国内特殊的平台环境，由于wikia没进来，于是目标用户都被百度（tieba）豆瓣、lofter、微博分流了。仅仅百度贴吧为例，一天就4亿+的PV。你想想这是一种市场已被瓜分完毕的假象，一般的投资者和创业者根本不敢涉足。&/li&&/ol&但是，其实不然。&br&我先简单说一些我对互联网产品以及wiki farm的个人见解。&br&&br&&b&任何一个互联网产品，他的产生都是为了迎合主流用户需求的，（有人做就意味着背后有人买单，呼声高了才会有人去投资，说白了大家都是为了逐利）否则都是耍流氓。比如&/b&&br&&ul&&li&人人是为了上同学（误）当有十万个学生想上同学的时候，renren出现了&/li&&li&微博是为了晒牛排和iphone，有一百万个人想低调晒xx的时候，微博出现了，&/li&&li&知乎是为了满足空虚寂寞冷装一把大神&a href=&/question//answer/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/question/2813&/span&&span class=&invisible&&3416/answer/&/span&&span class=&ellipsis&&&/span&&/a&&/li&&li&……那么同理&/li&&/ul&wikia（以及同样的wiki farm）是为了满足&b&谁&/b&的&b&什么&/b&需求而产生的呢？&br&首先wikia的用户，也就是“&b&谁&/b&”，就比较特殊，我把他的用户分成“生产者”和“消费者”，生产者就是编辑，消费者就是浏览者。和很多UCG不一样的是，wiki farm上的绝大多数内容是很小一部分人生产的。我举个简单的例子，冰与火之歌中文维基每天的pv在5~6万左右，但是编辑者不超过30个。&br&&ul&&li&wiki farm首先满足的是“生产者”（编辑）的生产需求。没有编辑就没有内容&/li&&li&wiki farm其次才满足了“消费者”（浏览者）的阅读需求。没有观众就不会赚钱&/li&&/ul&这个模式特别（或者说矛盾）的地方就在于，他的盈利模式相对滞后，赢利点主要取决于“消费者”，广告价是按照pv来收费的，没人看，自然卖不出去。 但是内容消费者是很惰性或者说随性的一个群体，绝大多数的人口味没那么挑剔，举个例子，一个marvel的漫迷，即使国内没有wikia，他可以去微博刷一刷#Avengers#，或者去mtime看一看时光专题，或者去豆瓣的comic小组瞅几眼，以及在贴吧、新闻都能获得一些零星的资讯（尽管可能是二手、不成体系的）。因此有着更高呼声和话语权的人群并没有不满，所以他们没有发声。&br&而真正有需求的那些“生产者”们——即核心的、骨灰级的geek粉丝，毕竟只是少数派，他们的呼声不足以产生质变，催生一个新的互联网产品。&br&所以在投资人和创业者眼里，这个需求是不存在的。&br&————————————————————————&br&但事实真是如此吗？我看未必&br&因为内容消费者，恰是互联网中最没有忠诚度可言的，一旦有了好的内容，他们分分钟跑给你看，大家都是为了更方便、耗时更少的看到更好更优质的内容，如果国内有一个Marvel Database，那么谁还会去看百度百科？&br&因此国内没有wikia这种专题型的自建wiki平台，原因有很多，最直接的就是大部分互联网创业者和资本的盲目短视造成的。市场还是存在的，需求也是存在的，混过贴吧豆瓣的都知道有爱的粉丝和群体是多么的有热情和创造力。&br&所以我认为只要解决了内容生产者的需求，即给他们一个一站式的Fansite解决方案，假以时日，我们也能孕育出本土的wiki farm品牌，从推特到微博，从quota到知乎都是如此。而且我认为wikia本身就问题多多，我们完全能够做出一个更好的平台。&br&——————————————————————&br&这么一个平台，从前没有，现在有一个，huiji.wiki（目前还在内测），我不打广告，有兴趣的朋友可以自己了解，自己判断：）&br&————————————————————————————————&br&P.S.可能有人会提到joyme，我并不想抹黑着迷，但是我认为他只是一个手游平台为了挽救用户，三心二意搞出的副业罢了，从骨子里就没有找到正确的方向和基因。所以我并不认为他是一个纯正的UGC wiki farm。
谢起名邀这个问题我之前详细的分析过（我先随便说几条（之前回答投资人的）用户基础的不成熟，我在另一个问题里面回答了一些，可以参考下： 很多人压根就没听过wiki farm这种东西，我遇到不少朋友，我跟他说wik…
建议题主把 自己 Wiki 的公网网址 发出来，大家别人可以从前端的角度 调试、诊断一下～
建议题主把 自己 Wiki 的公网网址 发出来，大家别人可以从前端的角度 调试、诊断一下～
网上有维基百科的mdx格式的数据包，2-3个g，用mdict可以打开，也可以用转换工具转换成文本
网上有维基百科的mdx格式的数据包，2-3个g，用mdict可以打开，也可以用转换工具转换成文本
来自子话题：
如同markdown的理念一样，所见及所得有时候会带来很多看不见却多余的HTML元素，维基百科注重的是内容，易编辑易阅读才是首要的。所见及所得未必是最易编辑的，熟悉了它的编辑器效率会很高。
如同markdown的理念一样，所见及所得有时候会带来很多看不见却多余的HTML元素，维基百科注重的是内容，易编辑易阅读才是首要的。所见及所得未必是最易编辑的，熟悉了它的编辑器效率会很高。
为了让作者能够专注撰写内容，而非费心于格式排版。同时，也让不同作者撰写的文章能有统一的格式与排版。&br&---------------------&br&当你开始认真思考、撰写文章的时候，只要敲字即可（甚至可以不用鼠标，像 Vi/Vim 是吗），保存文章的时候，“哗”的一下格式排版就完成了。这样的写作效率是非常高的。&br&当然，有些内容（如表格）还是有点复杂，所以 MediaWiki 提供了快速插入内容模板的简单功能。&br&我自己网站的内容编辑器也是类似理念，因为完全是自己开发的，深知这看上去简单粗糙的编辑器实现起来有多么复杂。
为了让作者能够专注撰写内容，而非费心于格式排版。同时，也让不同作者撰写的文章能有统一的格式与排版。---------------------当你开始认真思考、撰写文章的时候，只要敲字即可（甚至可以不用鼠标，像 Vi/Vim 是吗），保存文章的时候，“哗”的一下格式排…
我改词条都用可视化编辑器...不过也有缺点，比如我遇到的表格需要上下合并，我找了很久也找不到在哪儿...
我改词条都用可视化编辑器...不过也有缺点，比如我遇到的表格需要上下合并，我找了很久也找不到在哪儿...
来自子话题：
你要的VE：&br&&img src=&///6e1908145bdf99a053aebc_b.jpg& data-rawwidth=&1171& data-rawheight=&591& class=&origin_image zh-lightbox-thumb& width=&1171& data-original=&///6e1908145bdf99a053aebc_r.jpg&&记得用账号登陆才有。
你要的VE：记得用账号登陆才有。
维基媒体基金会正在开发可视化编辑器，称作&a class=& wrap external& href=&http://www.mediawiki.org/wiki/VE& target=&_blank& rel=&nofollow noreferrer&&VisualEditor&i class=&icon-external&&&/i&&/a&。&br&&br&MediaWiki标记语言是从2002年开始的，这十几年间，有什么feature的要求就加一个什么feature，结果是做成了一个非常庞大且复杂的标记系统，且可以说没有多少系统性可言，想实现它的功能只能一点点来做。同时作为一个&b&多语言程序&/b&，它要兼容所有的语言，为多种语言提供美式键盘下的输入能力，同时由于用户词库的原因又要兼容系统自带的输入法（最初曾一度做成捕捉键盘导致东亚几种语言无法使用），个别几种语言还要保证编辑结束后实现字词转换。更何况极为复杂的解析器函数、模板嵌套、高级CSS和表格用法等等能否实现都还是个未知数——必须强调：&b&MediaWiki系统的功能比起现有的所有主流网站的可视化编辑器都要庞杂&/b&。&br&&br&此外，MediaWiki的开发模式决定了不可能一次性搞定，也不可能在发布之前找一大堆人来debug，只能让志愿者充当debugger，边用边改，所以让可视化编辑投入使用的时候就完全实现标记语言的功能是不可能的。&br&&br&既然不能全部实现，那么现有的编辑器必须可以兼容可视化编辑和标记语言。因而VE需要&b&将编辑结果返回成标记语言储存&/b&，这也是VE最为困难的一点。VE刚推出试用的时候，甚至到了在可视化界面输入两对方括号（也就是最经典的标记符号[[链接]]）都无法做出任何合理处理的程度，实际上甚至几个月前还在解决类似这样的问题。&br&&br&综上所述，现在能登陆用户试用已经是很高的水平了。&br&我甚至一度不看好VE的前景。现在看他们大概是做出来一些了，但离应用还早。尤其是还有很多容易得多的新项目推进也极为缓慢，比如Flow。
维基媒体基金会正在开发可视化编辑器，称作。MediaWiki标记语言是从2002年开始的，这十几年间，有什么feature的要求就加一个什么feature，结果是做成了一个非常庞大且复杂的标记系统，且可以说没有多少系统性可言，想实现它的功能只能一点点来…
这是第二次回答自己提出的问题了，看来本人还是折腾摸索学入了门。&br&步骤：&br&（一）
搭建服务器环境&br&&p&简单的说就是：安装后找到程序根目录，找到www文件夹，复制wiki和wordpress文件。（网上好多人说的是放在一个更深的文件夹里，我不明白为什么）&/p&&blockquote&请参见&a href=&/freeyiyi1993/archive//3352387.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&windows下用wampServer 为wordpress 搭建本地服务器运行环境&i class=&icon-external&&&/i&&/a&&/blockquote&&p&（二）
从meidawiki（网络）到mediawiki（本机）&/p&&p&没想到mediawiki程序还挺开放的，根本不需要管理员权限就可以导出数据&/p&&p&“所有页面”——特殊:所有页面——导出数据——修改数据：通过notepad++的替换功能把日期改成最近几天，方便导出&/p&&blockquote&导出所有页面参见：&a href=&http://shanglei.net/hulianwang/mediawiki-export-backup.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&如何导出mediawiki的页面（用于内容备份或内容转移）&i class=&icon-external&&&/i&&/a&&/blockquote&&p&导入页面”从“特殊页面”进入，本地服务器有点脆弱，要导入N次才完毕。&/p&&p&（三）
从mediawiki（本机）到rss&/p&&p&为什么不直接从本站导出呢？因为本站导出rss有时间限制（最近N天更改），只能导出最近几天的词条。导入到本机后所有词条的作者都变成一个人了（记得替换用户名），时间也是最近几天。下面再次导出数据。导出rss很轻松：“最近修改”橙色按钮，保存即可。&/p&&p&（四）
从rss到wordpress&/p&&p&这一步简直是神坑！wordpress自带了个“rss”导入插件，然后导入之后全都是“All done. Have fun!”&/p&&blockquote&具体情况见&a href=&/question/& class=&internal&&通过 Google Reader 导出的.xml 文件，在wordpress 后台导入RSS，提示 All done. Have fun! ，但无数据导入，请问如何解决呢？
RSS链接见补充： - WordPress&/a&，这问题一直没人回答。&/blockquote&&p&然后就这样失败了N次之后…我明白了，这插件才1.4M，不靠谱，八成根本就没开发这功能。此时只需要换一个“feedwordpress”或“jps get rss feed”等类似插件即可&/p&&p&老外开发的东西就是不靠谱，不是要钱就是要折腾。有一个csstransport的网站可以直接把wiki生成wordpress网站，不过要100多美元……&/p&&br&&p&希望本文的读者不要拿这个作死复制别人网站的内容，否则我就是wiki界的罪人了…本来想回答“不要回答！”的…当然这个方法也引出了俩新的问题：&/p&&ol&&li&如何防止自己百科网站的内容被复制？&/li&&li&如何顺便导出单个词条链接而不是内链？&/li&&/ol&&p&希望有大牛解答！&/p&
这是第二次回答自己提出的问题了，看来本人还是折腾摸索学入了门。步骤：（一） 搭建服务器环境简单的说就是：安装后找到程序根目录，找到www文件夹，复制wiki和wordpress文件。（网上好多人说的是放在一个更深的文件夹里，我不明白为什么）请参见From MediaWiki.org
&translate&
This MediaWiki page is inactive and kept for historical interest.&/translate& &translate& It may document extensions or features that are obsolete and/or no longer supported.&/translate& &translate&
Do not rely on the information here being up-to-date.&/translate&
This page contains updates on the
project that were made between May 2011 and December 2014. It is no longer updated. For current news about the project's progress, see the
from the Editing team (, ) and before that VisualEditor (, , , ). For current information about VisualEditor's roadmap, see the .
have done exploratory work on the visual editor project. Neil
(a custom version of Etherpad, a real-time collaborative editing software) on a proof of concept of integration between Etherpad and MediaWiki (). They're now working on turning it into a MediaWiki extension. Work on the visual editor is also intersecting with the groundwork done on the new parser.
have done exploratory work on the visual editor project. Neil
(a custom version of real-time collaborative editing software Etherpad) on a proof of concept to integrate Etherpad and MediaWiki (). They're now working on turning it into a MediaWiki extension. Trevor continues to work on WikiDom, a storage structure and functionality acting as an intermediate layer between the parser and a visual editor. This work also intersects with the groundwork done on the new parser.
continued to work on the front-end of the visual editor, and specifications for accessing the editing surface via the API. A hybrid rendering approach appears to be the best strategy for the visual editor.
continued to work on the middleware, DOM and transactions. Neil also continued to work on a demo to integrate MediaWiki and . With , they planned their upcoming sprints. Neil and Trevor are posting about their work to .
continued to work on the front-end of the visual editor and he was joined by , a developer from Wikia, who are also interested in the visual editor.
worked on , concurrent editing and dived into the inner workings of Etherpad. (.)
worked on a transaction-based model for the visual editor, where the document is built as a series of events (instead of saving it entirely at every change), which makes it easier to undo actions.
continued to work on
and is close to presenting a demo of Etherpad working inside a MediaWiki edit window.
investigated and started to work on a chat system to be integrated to the concurrent editing interface, for collaboration and live help. More details .
expanded the . He also refactored some of the data structures to follow a model/view controller pattern and support document-level transactions. He wrote tests for the new structure, and got it to render
he's now working on rendering tables.
worked on a new model tree (and the conversion from the linear model) and updated the .
worked on front-end functionality: dialogs, selecting text, mouse actions, scrolling, keyboard shortcuts, etc.
focused on algorithms that insert ranges of data into a document, and
on the removal of data. On the parser side, a basic parser using PEG is in place, which produces an intermediate JSON
is still working on markup support (mixed HTML and Wikitext).
joined the team and started to work on the PEG parser ().
fixed issues blocking the synchronization of structural edits to the user interface, refactored and cleaned up the code, and mapped out
and . He also finished the document transaction functionality and made progress on an undo/redo system.
added tests, rewrote some code to make the tests pass, and fixed a number of bugs and issues, notably in Internet Explorer.
continued to work on content insertion, deletion and selection and fixed numerous bugs.
extended the
for robust larger-scale parsing. He converted the PEG parser into a combined wiki and HTML tokenizer that feeds to a HTML5 DOM tree builder. He implemented several wikitext features (lists, italics, bold) as token stream transformations. 139 of about 660 parser tests are now passing.
The first public developer prototype of the visual editor sandbox was deployed to MediaWiki.org for public feedback and testing. It can be accessed via the
special page.
in the Wikimedia blog.
The team deployed a developer prototype of the
to mediawiki.org for public feedback and testing.
fixed bugs and refactored code.
worked on the toolbar (text styles), the undo/redo stack, and lists (creating, deleting, and changing indentation).
worked on the parser test runner and the , including
and template expansions.
worked on the undo/redo feature and did a lot of refactoring.
January was a bit slower on the visual editor front, as parts of the team took some well-deserved vacation after the successful
in December. During the SF Hackathon, a lot of issues were fleshed out.
were formulated.
investigated a possible use of contenteditable to help with input methods and text selections on mobile devices.
with the ability to fetch and expand templates in a parallel and asynchronous fashion. The parser now supports most parts of the .
did research on cursor interaction and selection rendering for RTL (right-to-left) and support for line breaks in PRE elements.
improved template expansion and parser function support, investigated Microdata and RDFa for WikiText-in-HTML-DOM embedding and added rough support for images and other files.
committed a working Editable Surface IME prototype (bidirectional text not fully supported).
joined the team and worked on the sanitizer and the testing process.
Exploration of using ContentEditiable (CE) in place of EditSurface (ES) for the display layer was successful, and the team is integrating the new display layer system into the rest of the codebase. Inez and Christian are continuing their work on CE while Rob is focusing on getting the UserInterface (UI) module working with CE. Rob will be refactoring UI and adding an API layer for toolbar and inspector extensions. Trevor and Roan are focusing on DataModel (DM) changes that need to be done to improve tree sync and integration with the parser (Parsoid). Gabriel and Audrey are continuing their work on Parsoid.
Last week made big decisions. The big one was to move forward with contentEditable (CE) that Inez and Christian are doing in place of Editable Surface (ES). Looks like editing on mobile will be awesome!
will be focusing on the data model (DM. DOM -& Linear Parser) as the basic objectives have been hashed out, the (parser -& DM is unaffected). Certain structure changes (i.e. turning paragraphs to lists) aren't currently possible so the DM will change to support that. Linking with the parser (DOM-& LM converter) will be deferred for a week.
In terms of the UI,
worked on some RTL in ES, but switched given the CE advances. This week will focus on getting the UI working in CE (assess what UI we have from ES and where it needs to be). Plan on getting to the point we can user test the JS API for the toolbar.
In terms of the parser,
has to decide on RDFa vs. microdata eventually (difference are minimal, most of the DOM stuff won't change and can be tested with vanilla HTML anyway). Created a dump grepper with syntax highlighting and used that to analyze existing wikilink/image syntax use. Refactored tokenization and expansion of wikilink/images so now image options can come from templates (257 tests passing now). Plan on tackling interacting with action=parse and wiki in general. Also some more parser function tweaking, etc. and the RDFa/microdata decision.
Team updated (sans key people who are out of commission): . Further updates/corrections by Trevor and Gabriel expected when they return.
A big decision in March was to move forward with contentEditable (CE), implemented by Wikia developers
and Christian Williams, instead of Editable Surface (ES).
focused on the data model.
worked on the user interface, first on right-to-left support in ES, then on getting the UI working in CE.
continued their work on
and need to decide on RDFa vs. microdata. They created a dump grepper with syntax highlighting, and used it to analyze existing wikilink/image syntax use.
are rewriting the underlying data model (ve.dm) to achieve feature compatibility with the parser and correct a variety of problems that have been previously deferred.
and Christian Williams have been continuing their work to stabilize and integrate the content editable layer (ve.ce) and have been working with , who has focused on getting the user interface elements working with the content editable layer (ve.ui).
has been working on improving the 's ability to parse pages more quickly as well as increasing compatibility with existing features such as thumbnails. A big template-heavy page like
can now be expanded in similar time as the production parser (80 seconds on a puny laptop) and 340MB of memory. It previously ran out of memory after consuming 1.6G and running for ~30 minutes.
BY JUNE! 5 weeks.
What we want:
parse page
load editor
save it back
not hard to load simple pages
but not roundtripping it (because not all tags are supported)
Serializaiton: some normalization. focusing efforts on reconcilliation instead?
For Roundtripping: Need more support. Handle templates (started by one and ended by another), also template parameters. (linear model supports both: but data model only allows edit templates parameters on opening).
Just finished Refactoring so it can expand big articles. A few more days left of followup.
Serializer:
"Alien Nodes" (HTML we don't understand)
acknowledge that dirty diffs will happen.
Have a sandbox deploy, create a namespace for it.
Roundtrip something!
Probably a namespace limit, sandbox
allow dirty diffs or disallow manual editing and start from scratch.
If source editing, then it will run it through the parser as a presave transformation. Warning banner with X? so may not have source mode editing only if developer mode.
Maybe Gabriel can refocus on serialization (worried abotu stuff that will be shifting).
get it ready incremental improvements on front-end, but on the serialization and back-end that will change.
James Forrester:
sooner is better. :-)
He will need to be on board for the release in (late) June
Things to be done for release:
Gabriel needs to refocus on serialization (for roundtripping) after he gets the refactor settled (next couple days)
Finish DM rewrite stuff. As soon as it is in master then we start doing integration.
This week: Get feature completeness with transactions]
On FE, rework observation stuff, toolbar into the DM stuff as it comes along.
Annotation should be working today.
Integration work?
MW integration [Roan]
FE integration- do a "ooh and ahh" it.
Node.js integration [Gabriel will get working, and Roan will puppetize and give to Ops]. Roan has Node.js installed on a VM project.
Release Notes: Dec to June (reason)
Switch from ES to CE (due to CE, This warrants a blog post)
Mobile editing support (due to CE, Patrick can hack up something)
February stuff: Supports spellcheck, autocorrect, IME (due to CE)
turn headline into paragraph
feature parity w/ previous demo (internal check)
Load and save (parser/serializer, backend integration)
In-place editing (frontend integration)
Graceful failure/fallback (AlienNode)
[TBD] partial iage support (DM rewrite)
Trevor will make a task list in-wiki. If it doesn't work out, will consider to switching to .
Tracking ongoing work:
Gabriel has set up a very basic .
browse english wikipedia as parsoid sees it
POST wikitext -& HTML DOM
POST HTML DOM -& wikitext.
Note: round-tripping is limited. Does not support preservation of variable whitespace, templates and other complex constructs yet.
Currently 154 parser tests are passing in the new --roundtrip mode that Subbu added last week.
The team completed
for June and welcomed
as the Technical Product Analyst for the project. Ongoing work on the
is tracked on-wiki.
set up a very basic
that lets users browse the English Wikipedia as Parsoid sees it, and convert Wikitext to HTML DOM and vice versa.
The team did the , with an early version now live in a test namespace on mediawiki.org. This editor is broadly feature-compatible with the old, EditableSurface-style code which this replaces, while being the first release that can create and edit pages. The team is now planning to deploy new code as it develops every two weeks or so. The initial push will be to work on bug-fixes, and to finalise the code for a few features that were close to being ready before the first deployment.
The VisualEditor (VE) team presented their work at Wikimania and received a good deal of feedback from the community. The team created . The early version of VE on mediawiki.org was updated twice, fixing a number of bugs and noticeably including the addition of support for nested lists. Gabriel Wicke relocated to San Francisco, and Timo Tijhof visited the SF office for three weeks after Wikimania.
In August, the team focused on overhauling the code design of VisualEditor so that it is more modular and easier to extend. This involves creating and documenting a number of formal APIs at each point in the architecture, that means a developer does not have to understand the entire code base to be able to add new features. The early version of the VisualEditor on mediawiki.org was updated twice ( and ), fixing a number of bugs, as well as adding a much-improved link inspector to help users build links, and a save dialog that better guides users on what to do.
In September, the team continued its focus on re-engineering the code design of VisualEditor so that it is more modular and easier to extend. This involves creating and documenting a number of formal APIs at each point in the architecture, that means a developer does not have to understand the entire code base to be able to add new features. The early version of the VisualEditor on mediawiki.org was updated twice ( and ), fixing a number of bugs and building out better support for internationalisation and key concepts like categories, language links and other "magic words".
In October, the team worked to finish most of the re-engineering the code design of VisualEditor so that it is more modular and easier to extend. This has involved creating and documenting a number of formal APIs at each point in the architecture, so a developer does not have to understand the entire code base to be able to add new features. The early version of the VisualEditor on mediawiki.org was updated three times (,
and ), fixing a number of bugs and replacing the entire browser selection and typing models, and much of how the user interface connects with the rest of the code.
In November, the team worked primarily on finalizing the code re-engineering of VisualEditor so that it is more modular and easier to extend, and on the integration ahead of deploying it for wider testing in December. The early version of the VisualEditor on mediawiki.org was updated twice ( and ), fixing a number of bugs and missing wikitext compatibility, and wide-spread improvements to much of the user interface code so that it will be easier to change in future.
In December, the team
an alpha version of the VisualEditor for editors to use and give feedback on issues and priorities. The team's work focussed on ensuring that the integration was reliable, and providing a dedicated tool for editors to report problems with editing, and, after deployment, addressing the reports and ideas from editors. The early version of the VisualEditor on mediawiki.org was also updated to use the new developments (as part of ).
In January, the team worked primarily on reviewing and cleaning-up the code
in December. They spent time with their colleagues in the Parsoid team planning the next phase of development, which is aimed at making the VisualEditor the default editor for all Wikipedias from July 2013. The alpha version of the VisualEditor on mediawiki.org and the English Wikipedia was updated twice ( and ), fixing a number of bugs reported by the community and making some adjustments to the link inspector's functionality based on feedback.
In February, the team worked on improving the design, user interface components and API infrastructure of VisualEditor, preparing for the new features that will be added in the coming months. The objective is for VisualEditor to be the default editor for all users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. This will mean adding support for references, (at least) basic templates, categories and images, each of which is a very large piece of work. During this time, the team has expanded with the recruitment of , who will focus on the data infrastructure of VisualEditor's platform. The alpha version of VisualEditor on mediawiki.org and the English Wikipedia was updated twice ( and ), adding support for Microsoft Internet Explorer (version 9 and above), fixing a number of bugs reported by the community, improving internationalisation, and restructuring the data model layer so that the code interfaces are ready for the new features.
In March, the team worked on the major new features that will be added in the coming months. The objective is for VisualEditor to be the default editor for all users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. This will mean adding support for references, (at least) basic templates, categories and images, each of which is a very large piece of work. This month the primary focus was editing of categories and templates, with draft designs created and initial code developed. The team undertook its first ever "", whose
detail these designs, the work done to date and expectations for the near future. The alpha version of VisualEditor on mediawiki.org and the English Wikipedia was updated twice ( and ), adding better input and selection support, fixing a number of bugs, and restructuring the back-end so that the new features will be simpler to create.
In April, the team continued their work on the major new features that will be added in the coming months. Our objective is for VisualEditor to be the default editor for all Wikipedia users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. This means we have been focussed on four substantial areas of work: adding support for references, templates, categories and media items. During this time the main area of our work was editing around images, which is now designed and partially implemented in our experimental code, and around categories, which is almost complete and nearly ready for deployment. The deployed alpha version of VisualEditor was updated thrice (,
and ), adding speed improvements, user interface improvements and work on the back-end to better support the new features, and fixing a number of bugs. We also were able to
(and, later, Vietnamese Wikipedia too), which has let the community give us feedback on what works and is broken, and identifying language- and locale-specific issues we are now fixing.
In May, the VisualEditor team worked to complete the major new features we have prioritised over the past few months. Our objective is for VisualEditor to be the default editor for all Wikipedia users, capable of letting them edit the majority of content without needing to use the wikitext editor, in July 2013. We have focussed on four areas of new functionality: adding and editing inclusions of references, templates, categories and media items. Our main area of work over the past month has been on references and templates, and we now have implemented editing them in o category editing is nearly complete and should be made available very soon. The deployed alpha version of VisualEditor was updated twice ( and ), adding a number of user interface improvements, including further work on the back-end to better support the new features, and fixing a number of bugs.
In June, the VisualEditor team completed the major new features that we prioritised over the past few months, in preparation for making VisualEditor available to most Wikipedia users in July. We have built an editor that is capable of letting users edit the majority of content without needing to use wikitext — text support, as well as adding and editing inclusions of references, templates, categories and media items. The deployed alpha of VisualEditor was updated four times as part of the transition to weekly deployments (, ,
and ), with several mid-deployment releases as the code was developed to patch urgent issues. Part of this involved running an A/B test for new user accounts on the English Wikipedia, with half of the users getting opt-in to VisualEditor ahead of the wider release. Generally, there were a number of user interface improvements, and fixing a number of bugs uncovered by the community.
In July, the VisualEditor team began switching the deployment from opt-in alpha to opt-out beta, so becoming the default editor for users of the various Wikipedias. The deployed version of the code was updated three times (,
and ), with several mid-deployment releases as the code was developed to patch urgent issues. There were a number of user interface improvements, most notably to the references insertion dialog, alongside fixes to a number of bugs uncovered by the community.
In August, the VisualEditor team continued work, and presented and ran workshops at
to discuss how to best improve the system. The deployed version of the code was updated three times (,
and ), with several mid-deployment releases as the code was developed to patch urgent issues. The focus in this work was in improving the stability and performance of the system, fixing a number of bugs uncovered by the community, and making some usability improvements.
In September, the VisualEditor team continued their work to improve the editor and roll it out to additional wikis. The deployed version of the code was updated four times (,
and ). The focus in the team's work this month was to continue to improve the stability and performance of the system, fix a number of bugs uncovered by the community, and make some usability improvements.
In October, the VisualEditor team continued to improve the stability and performance of the system, and add new features. The deployed version of the code was updated five times (, , ,
and ). Beyond fixing bugs, the focus of the team's work this month was to make a number of large structural changes to make the system more dependable and extensible, and continue to make some usability improvements. For example, you now need to press the "delete" key twice to delete a template, the first time, they only become selected, to avoid accidental deletion of infoboxes and similar content. A new feature, empowering users to switch from editing in VisualEditor to editing wikitext directly without having to save the page, was also implemented.
Presentation slides from the
on 7 November.
In November, the VisualEditor team continued to improve the stability and performance of the system, and add new features. The deployed version of the code was updated three times (,
and ). Most of the team's focus was on fixing bugs, and on some major infrastructure changes, splitting out the
libraries from VisualEditor to make them available to other teams. Much of the team travelled to the
in Pune, India to learn more about how to improve VisualEditor for a variety of languages, scripts, users and systems. Two new members of the
joined in to help improve VisualEditor –
and , and thanks to them, the automated browser tests have expanded in breadth and depth of coverage. Work continued on major new features like full rich copy-and-paste from external sources, a dialog for quickly adding citation templated references, and a tool to insert characters not available on users' keyboards. The editor was made available by default on just over 100 additional Wikipedias as part of the continuing roll-out. VisualEditor was also enabled for opt-in testing on Swedish Wiktionary and Wikimedia Sweden's wiki, the first time it has been available on a non-Wikipedia production wiki.
In December, the VisualEditor team worked to continue the improvements to the stability and performance of the system, and to add new features. The deployed version of the code was updated three times (,
and ). Most of the team's focus was on major new features and fixing bugs. There is now basic support for rich copy-and-paste from external sources into VisualEditor, and a basic tool to insert characters not available on users' keyboards. Work also continued on a dialog for quickly adding citation templated references, and on some major infrastructure changes, splitting out the core of VisualEditor from the MediaWiki-specific items like the transclusion editor.
In January, the VisualEditor team continued their work on improving the stability and performance of the system, and added some new features. Most of the team's focus was on major new features and fixing bugs. You can now edit some page settings like whether to display a table of contents or whether to show section edit labels, set the size of a media file manually, see a keyboard shortcuts help screen, and create and edit media galleries using a very basic stand-in editor whilst the final form is being designed. Work also continued on a dialog for quickly adding "citation" references based on templates, more media and page settings, setting content language and right-to-left flags, and equation editing. The deployed version of the code was updated four times (, ,
In February, the VisualEditor team continued their work on improving the stability and performance of the system, and added some new features and simplifications. Media item editing is now much richer, allowing the setting of position, alt text, size (or setting as default size) and type for most kinds of media item. When adding links, redirects and disambiguation pages are now highlighted to help editors select the right link, and changing the format or style of some text was tweaked to make editing clearer and more obvious. Adding and editing template usages is now a little smoother, auto-focussing on parameters and making them clearer to use. Page settings have expanded to set redirects, page indexing and new section edit link options. The extensive work to make insertion of "citation" references based on templates quick, obvious and simple neared completion. The deployed version of the code was updated four times in the regular releases (, ,
Presentation slides from the
on 26 March.
In March, the VisualEditor team continued their work on improving the stability and performance of the system, and added some new features and simplifications, helping users edit and create pages more swiftly and easily. Editing templates is now much simpler, moving most of the advanced controls that users don't often need into a special version of that dialog. The media dialog was improved and stream-lined a little, adding some hinting to the controls to explain how they work a bit more. The cursor entry points inserted by VisualEditor next to items like images or templates to give users somewhere to put the cursor now animate on hover and cursor entry to show that they're special. The overall design of dialogs and controls was improved a little to make it flow better, like double-clicking a block to open its dialog. A new system for quickly and simply inserting and editing "citations" (references based on templates) neared completion and will be deployed in the coming month. The deployed version of the code was updated four times in the regular releases (, ,
In April, the VisualEditor team worked to improve the stability of the editor, adding some new features and improving usability so that users can create and edit pages more swiftly and intuitively with VisualEditor than before. Template editing was over-hauled to make adding parameters less busy, showing only a few parameters at first rather than all possible ones, which can number in the dozens or more, especially in the case of some often-used templates like those for citations or infoboxes. Setting the size of images was tweaked to give a more natural set of controls based on feedback from users. The page settings dialog had a number of minor tweaks, leading to the set of options that can be modified inside VisualEditor being completed. VisualEditor's edit tab is now more consistent with the rest of the MediaWiki interface in a number of noticeable if minor ways, such as on pages to do with the Education Program, on file pages which are hosted on Commons rather than on the local wiki, or on very narrow screens. User testing was carried out on the forthcoming citation dialog and some final simplifications were made, such as adding suggested as well as required parameters, ahead of its pending introduction. Finally, a careful audit of all Wikimedia wikis led to fixing broken local community-written code, to ensure that VisualEditor runs on all of them. The deployed version of the code was updated four times in the regular release cycle (, ,
In May, the VisualEditor team worked on the performance stability of the editor, rolled out a major new feature to help users better edit articles, and made some improvements to other features to increase their ease of use and understandability, fixing . The new citation editor is now available to all VisualEditor users on the English, Polish, and Czech Wikipedias, with
on how to enable it on other wikis. The citation and template dialogs were simplified to avoid technical language and some outcomes that were unexpected for users. As part of this, the citation icons were replaced with a new, clearer set, and the template hinting system now lets wikis mark template parameters as "suggested", as a step below the existing "required" state. The
is now available to all VisualEditor users, and a new Beta Feature giving a tool that lets you
was made available for testing and feedback. Following a new set of user testing, the toolbar was tweaked, moving the list and indent buttons to a drop-down to make them less prominent, and removing the gallery button which is rarely used and confused users. The mobile version of VisualEditor, currently available for alpha testers, was expanded to also have the new citation editor available, and had some significant performance improvements made, especially for long or complex pages. Work continued on making VisualEditor more performant and reliable, and key tasks like keyboard accessibility have progressed. The deployed version of the code was updated five times in the regular release cycle (, , ,
In June, the VisualEditor team provided a new way to see the context of links and other items when you edit to make this easier, worked on the performance and stability of the editor so that users could more swiftly and reliably make changes to articles, and made some improvements to features focussed on increasing their simplicity and understandability, fixing . The editor now shows with a highlight where dragging-and-dropping content will put it, and works for any content, not just for images. The citation and reference tools had some minor adjustments to guide the user on how they operate, based on feedback and user testing. A lot of fixes to issues with windows opening and closing, and especially the link editing tool, were made, alongside the save dialog, categories, the language editing tool, table styling, template display and highlights on selected items. The mobile version of VisualEditor, currently available for alpha testers, moved towards release, fixing a number of bugs and improving performance. Work to support languages made some significant gains, and work to support Internet Explorer continued. The new visual interface for writing TemplateData was enabled on the Catalan and Hebrew Wikipedias. The deployed version of the code was updated four times in the regular release cycle (, ,
In July, the team working on VisualEditor converged the design for mobile and desktop, made it possible to see and edit HTML comments, improved access to re-using citations, and fixed .
The new design, with controls focussed at the top of each window in consistent positions, was made possible due to the significant progress made in cross-platform support in the UI library, which now provides responsively-sized windows that can work on desktop, tablet and phone with the same code. HTML comments are occasionally used on a few articles to alert editors to contentious or problematic issues without disrupting articles as they are read, so making them prominently visible avoids editors accidentally stepping over expected limits. Re-using citations is now provided with its simple dialog available in the toolbar so that it is easier for users to find.
Other improvements include an array of performance fixes targeted at helping mobile users especially, fixing a number of minor instances where VisualEditor would corrupt the page, and installing better monitoring of corruptions if they occur, and better support for right-to-left languages, displaying icons with the right orientation based on context.
The mobile version of VisualEditor, currently available for beta testers, moved towards stable release, fixing a number of bugs and editing issues and improving loading performance. Our work to support languages made some significant gains, nearing the completion of a major task to support IME users, and the work to support Internet Explorer uncovered some more issues as well as fixes. The deployed version of the code was updated five times in the regular release cycle (, , ,
In wider news, the team expanded its scope to cover all MediaWiki editing tools as well, as the new Editing Team (covered below).
In August, the team working on VisualEditor presented about VisualEditor at , worked with a number of volunteers at the hackathon, adjusted key workflows for template and citation editing, made major progress on Internet Explorer support, and fixed .
Users of Internet Explorer 11, who we were previously preventing from using VisualEditor due to some major bugs, will now be able to use VisualEditor. Support for earlier versions of Internet Explorer will be coming shortly. Similarly, tablet users browsing the site's mobile mode now have the option of using a mobile-specific form of VisualEditor. More editing tools, and availability of VisualEditor on phones, is planned for the future.
Improvements and updates were made to a number of interface messages as part of our work with translators to improve the software for all users, and VisualEditor and MediaWiki were improved to support highlighting links to disambiguation pages where a wiki or user wishes to do so. Several performance improvements were made, especially to the system around re-using references and reference lists. We tweaked the link editor's behaviour based on feedback from users and . The deployed version of the code was updated three times in the regular release cycle (,
In September, the team working on VisualEditor expanded browser support, improved some features, and fixed .
Users of Internet Explorer 10, who we were previously preventing from using VisualEditor due to some major bugs, will now be able to use VisualE this follows on from Internet Explorer 11 support last month. When editing a template with a required field, VisualEditor now warns you to avoid leaving it blank, and you can now create auto-numbered links using VisualEditor.
Improvements and updates were made to a number of interface messages as part of our work with translators to improve the software for all users, based on feedback from users and . We made progress on table structure editing and auto-filled citations, both of which will be coming soon.
The deployed version of the code was updated five times in the regular release cycle ( , ,
In October, the team working on VisualEditor improved some features, prepared the way for table structure editing, and fixed .
The keyboard shortcuts for items in the toolbar's menus now show on the right hand side, to make them easier to find. We made a few improvements to the display and editing of templates. Firstly, template fields can now have a value automatically set, like today's date for clean-up notices. Links inside templates now show in red if their targets don't exist, like for the editing surface. Last month's change to warn against saving a template with missing required fields was improved by highlighting them, as is the warning about trying to make an image 0 pixels wide.
The initial tools to edit the structure of tables were finalised and will be made available next month. We made progress on providing a new
tool, and improvements to the
tools, all of which will be coming in the near future.
The deployed version of the code was updated five times in the regular release cycle (, ,
In November, the team working on VisualEditor introduced table structure editing, improved some existing features, and fixed .
You can now edit the structure of a table, adding or deleting rows and columns and various other common tasks like merging cells and using captions. VisualEditor now support keyboard shortcuts like entering "* " at the start of a line t if you didn't mean to use the "smart" sequence, pressing undo will get back to what you typed. Most wikis now have VisualEditor available as an opt-in tool, whereas previously communities had to ask for it to be switched on.
The toolbar's menus in VisualEditor now open in a collapsed, short form with uncommon tools only shown when requested. You can now create and edit simple "blockquoted" paragraphs for indenting. You can now use a basic editor for gallery and hieroglyphic blocks on the page. Category editing was enhanced in a few ways, including adding a redirect category now adds its target, and making categories without a description page show as red. We improved compatibility with some variations of how wikis use the Flagged Revisions system. Armenian language users now get customised bold and italic
if your language would benefit from customised icons, please .
We also made progress on providing a new
tool, and improvements to the
tools, all of which will be coming in the near future.
The deployed version of the code was updated four times in the regular release cycle (, ,
In December, the team working on VisualEditor introduced a new design for the front-end system that VisualEditor uses, improved several existing features, and fixed .
The new design of the interface is based on the future path set by the , and is intended to gel with designs across Wikimedia's tools and services and the wider direction of travel for the Web as a whole. The interface is subject to revision and improvements, and not feedback is appreciated from users and designers alike.
We also made a number of improvements to language editing and browser stability, progress on providing a new
tool, and improvements to the
tools, all of which will be coming in the near future.
The deployed version of the code was updated three times in the regular release cycle (,}
我要回帖
更多推荐
- ·渐行渐远的民国故事：国民党十大黄埔军校还存在吗名将的最后结局目录
- ·PE是什么简称意思？
- ·老人死了怎么到私下查他人银行流水查流水
- ·CDR怎样让word怎么让左右文字都对齐对齐
- ·宝剑是管制刀具吗砍得断枪管吗？
- ·亲帮忙很重要的事情 哥哥求你放了我了
- ·QQ主题分组图片qq分组怎么换字体啊，怎么都设置不了呢？
- ·你好 你发的那个文明5修改的修改工具怎么用
- ·你们说被封的QQ号眼镜500度还能复原么吗？
- ·苹果5s升级ios8.4好吗一次和多次有区别吗
- ·那位大神知道这个垃圾是大神note3什么牌子子
- ·求大师，谁能帮帮我这个忙，遇到小伙子的大麻烦烦了。。。
- ·oppo手机应用图标怎么变成oppo开关机动画下载了
- ·oppo手机隐藏图标应用图标怎么变成动画了
- ·波粒dvr98089808监控软件下载
- ·全本免费潇湘书院全本完结小说说阅读陆少的暖婚新妻二十一章
- ·我这里有 微，信 软件 微信避开最小包添加源控制 位数 加我微 信aa62158
- ·求太平洋战争片剪辑非剪辑版
- ·我在图库里面设置了一个思密空间怎么也cad里面找不到打印机了
- ·wiki如何安装itween visual editoreditor
- ·求帮忙注册求一个绅士道账号的账号qwq，加q10369140
- ·快手打开没有视频他是怎么设置视频默认打开方式的?
- ·苹果系统可以装cad吗手机可以自在公式软件系统吗
- ·消消乐如何求助过关关
- ·跪求此图出处处啊
- ·allshare play是什么 log文件是什么，有什么用，而且也删不掉，删了又出来了
- ·求终结者外传第一季高清资源
- ·有谁可以借我借贷宝注销账户怎么弄用几天，保证不会擅自改写资料
- ·求 『指环王3：国王归来』的英文字幕，只要英文，全英文，ass格式，谢谢！
- ·那里能看这两个人才应该爱到老老了时间全本小说
- ·国行iphone6国行能用电信的msn不能用吗
- ·打印机，只打文字和打印机excel表格无法打印，买墨盒还是买改装连供？
- ·荣耀7能用普通nanosim卡自己剪还是去换剪成的nano nanosim卡自己剪还是去换吗?
- ·6229911670023257030是哪个行的座机号码查询
- ·空调器是什么机新冷谋是什么
