Shown when there's no template data.
Someday in the future, we will support adding a description inline. Not
yet. Calm down.
Change-Id: I18c0a591b60de53bc124d82c688d71d30ad1d5dd
Also update VE-MW for the comment changes in VE core
New changes:
4ad6a3d Add text direction to SA demo
89503e8 ve.ce.Node: Emphasise slug transition with increasing outline offset
864046e Update oojs to v1.0.8
65d1338 Localisation updates from https://translatewiki.net.
b66d482 Stop special-casing comments and recognize them as tagName='#comment' instead
09dda12 ve.ce.getDomText: Document node types and use .data instead of .nodeValue
b0a3b2a Make ve.dm.Converter assertions actually display message
ef791cc Make 'comment' its own metaitem type
d5ef0d7 ve.dm.Converter: Refer to nodes instead of elements where appropiate
c22c8af Fix JS error when pressing Enter with selection across multiple paragraphs
a26a708 Add ve.dm.Transaction.newFromReplacement
a9e136e Don't cause needless surface refreshes on overwriting.
6fd35ee Split part of getOpeningHtmlTag out to getHtmlAttributes
2c31f67 ve.ce.Surface: Document version number in focus workaround for Opera
e069e74 Add some more characters to the special character inserter
Change-Id: I859805fb261468e8fae9454c4992115369066b49
* Use "Insert template" when adding a single template
* Use "Insert transclusion" when adding a multi-part template
* Use "Apply changes" when working with an existing tranclusion
* Use "Loading..." and disable while waiting for template data
* Disable when the transclusion has only a template placeholder
Bug: 50998
Change-Id: Ib2fb3d8711ed6d3ef41cc0db55740c95394dd3f9
Initially we were only deploying to $wgContentNamespaces, but it's highly likely
that users will want to edit their own user pages in VE anyway. Note that this is
how it's been deployed for Wikimedia for a year now.
Additionally, this helps fix a bug in the browser tests that assumed NS_USER was
a VE-able namespace when that was only true in production config, and not for new
wikis (such as created during automated setup).
Bug: 57104
Change-Id: Icebc24f82fb49e9e80388b6202efa366360ce33c
The experience should be consistent between mobile and desktop.
We should explore re-styling these buttons to look like
Ib3c94d19231b018a509b78269001223ad0568795 in desktop as well
at a later date.
Change-Id: Ic9e4c5d12c3c75fcb195432c9155ec0a7eecac04
Split tracking out of the base target and from viewPageTarget
Primary reasons for this change:
* Makes it possible to resolve an issue with tracking in mobile
* Lets us reuse the viewPage save workflow tracking
* Support existing and new targets with tracking
* Simplification of target classes
Change-Id: I036e4f2129d929db0a3b9a4baa87c946a4b194a9
Not removing the existing message for "Transclusion" for now in case
that's needed later.
Bug: 55434
Change-Id: I0ee722e821051970b4a445b5a7a0e93f144f3185
* Automatically select single mode when possible
* Allow dynamic switching when possible
* Hide most of the controls and information when in single mode
* Allow parameter model to be instantiated without name and value args
* Place add param buttons at the bottom of template and param pages
which are only visible when in single mode and on the last page
Change-Id: Iaffbf1863b808c8089dfcf09a976d165f28c8b74
Remove GroupButtonWidget since it was removed in VE core.
New changes:
22edcd9 Special character inspector styling
Change-Id: I385d6b655686c753262258714dec06f8b1e5fc10
There are several conditions to defaultSize behavior of thumbnails and
frameless images and other images when it comes to default size. In the
same principle is 'border' which is not quite a type despite the fact
it 'behaves' as such in wikitext (and has a unique identifier that comes
instead of the other types.
This commit aims to organize this behavior for the user in an
understandable manner.
* Add 'basic' image type for images that have no specified type ('none')
* Handle the difference in 'default' size behavior between basic images
and thumbnails/frameless. The thumb/frameless images have the default
wiki size. Other images' default size is their original dimensions.
* Force wiki-configured default size for thumbnails and frameless images
in the DM. This is done because at the moment Parsoid's output is of
Wikipedia's default size rather than the local wiki's. The size is
adapted if needed, directly in the DM.
* Added 'border' as a pseudo-type checkbox flag that sets css class
'mw-image-border' is for parsoid rendering on save.
* Add 'make full size' to the size widget select and treat it as a faux
default button for basic and frame images.
Bug: 62013
Bug: 62024
Bug: 61155
Bug: 61059
Bug: 61282
Change-Id: I6778705306f0dd6bb96afeb91383089a4ddab7ed
Also add MW configuration for ModelRegistry back, was removed in core.
New changes:
564c459 Localisation updates from https://translatewiki.net.
f30e061 Consistency in test header comments
74be717 Remove MW-specific config and genericise tests in ModelRegistry
Bug: 53148
Change-Id: I67e77bd41bbff52f88632ff9e4cf5e4c48251174
* Show label, input and remove control on a single line
* Right align label to conserve vertical space without sacrificing
fill-out speed
* Show description in gray text below the input
* Show remove button only when page is active
* Make description lighter when page is innactive
Change-Id: Iaa09f3bf909ccd415de7af8f428495fef3046893
Because everything was broken.
Follows-up I6374854eaa1 which split up mwcore into smaller parts but
left MWDialogTool still as one file part of mwcore. Since the various
ve.dm classes are now part of the other modules that depend on mwcore,
the MWDialogTool classes were pointing at classes that don't exist yet
(e.g. ".modelClasses = [ ve.dm.MWBlockImageNode ];").
Change-Id: Ic05b173d730a8a0f6539fdcd818aaf674d2a4019
This gives users a clue to understand why they won't display in the
category box at the foot of the page.
Bug: 50763
Change-Id: I1cf3a76bbf6370e7f67ec16f0a931f6ea4ba9d28
We can't change tooltips once they're set for buttons like this (they're
static), so for values that can change we need to use language that does
not need plurals.
Bug: 61891
Change-Id: I78e5576e348ee92bc39315fd494b3398ae2c14bf
Core retains core functionality, including text styling and architectural
items like dialogs.
The new modules are:
* mwformatting
* mwimage
* mwlink
* mwmeta
* mwreference
* mwtransclusion
The new modules are loaded in ViewPageTarget (for desktop), except for
mwlinks which is included from MWTarget (for desktop and mobile), per the
needs of the Mobile team.
Also, mwgallery was moved to desktop-only loading status.
Some styles which were loaded in mwcore but only used in modules is now
loaded in said modules.
This does not split up ext.visualEditor.core yet, which is left as an
exercise for the fool-hardy.
Bug: 61075
Change-Id: I6374854eaa13af824c11078d2f7004dc8a211a30
* The name was getting super long, and the Template prefix doesn't
appear to be important.
* Soon we will add a placeholder class, which would have been
MWTemplateParameterPlaceholder, but now just MWParameterPlaceholder
which seems a little less ridiculous.
Change-Id: Ie2dfe0d4c7b960cd554f89fa6340173e8786c88a
This commit makes several adjustments to make sure default size is being
handled correctly:
* Add wiki's default size configuration parameter to the
VisualEditor.hooks.php file so it can be called from VE.
* Make sure new images are inserted with default size and are
marked 'defaultSize = true' for the DM to handle.
* Force default size if 'defaultSize=true' in the DM
* Add a 'default|custom' switch to the media edit dialog for size
inputs. When 'default' is chosen, the media size widget will be
emptied, displaying its placeholders (default size)
* When the size widget's values are 0 it will automatically turn to
default size values. If the value started default and the user
typed in a size, it will automatically override default and use
custom size.
Bug: 47804
Change-Id: Ib973ea2afa96090a4ba61b2b55ee63457f1329c1
VE init sets up access keys in some cases, but they have not
been set to the correct string for the browser until mw.util.init
has been called, so add a dependency on mw.page.startup to the
init module.
Change-Id: I494b364b485e678122e7f235df88b80fb503fa94
Added checkbox to set position (left/center/right) or none if unchecked.
Also handle 'default' position based on the wiki direction.
Bug: 61155
Change-Id: Iddd78c98929759a13d2dc5a774e72b59cbe28c36
We don't yet have any way to test or verify anything with less. Not the less
syntax, not the less compilation, not the resulting css code quality.
Using it at this point doesn't seem worth the cost of not having any of that.
This reverts commit 17ddf031fe.
Change-Id: I7e8ab90f7a9f77f5cf6d7baeab586d4e0332042e
Just doing simple nesting for now. No mix-ins or variables.
There are no actual style changes in this commit.
Change-Id: Ied29358d39703ca6d2c896c2d44d9cf397d51d4e
Add a trinary option to the page settings pane of the meta dialog that
lets users set the page to have __NEWEDITSECTION__, __NONEWEDITSECTION__,
or neither (and so have default behaviour).
Bug: 57168
Change-Id: I3198409c6aaa4cbce7e26fd56d390ffc91e91eef
Add a trinary option to the page settings pane of the meta dialog that
lets users set the page to have __INDEX__, __NOINDEX__ or neither (and so
have the default behaviour).
Bug: 57167
Change-Id: I30d483b5b6c3df7ee56a52c744bbdc610a01873d
The styling of the image thumbnails should be controlled at the
skin level, not by the generic VE styles. Moving the thumb/figure
styles from ve.ce.Node.css to ViewPageTarget-shared.css. Otherwise
no changes to the styles themselves.
Also adding minerva (the mobile skin) to the list of supported skins.
Bug: 60542
Change-Id: I67ab6d5b91cee7e587f61df26e7dae74c1068788