Return an array of languages instead of a single language. Languages
containing hyphens return themselves along with the root code e.g.
'en-GB' => ['en-GB', 'en']
Change-Id: I840b689d0021d865f93d16d075473a2ed0a9f0d8
The old regex was lifted from PHP, which matches on UTF-8 byte sequences.
In PHP, [...\x80-\xFF]+ matches any bytes with the high bit set, which
by the particular properties of UTF-8 will match any sequence which
represents a Unicode character above U+007F.
In Javascript, regex matching is on UTF-16 Unicode code units, so we
don't have to do byte sequence matching (and cannot do so). So the
equivalent Javascript regex should use [...\u0080-\uFFFF]+, to match any
code unit above U+007F directly. (It also matches surrogate pairs, by
the particular properties of UTF-16, so any Unicode codepoint above
U+007F is matched).
Change-Id: I674b89f757b60331dd1cb23fd7ff8b18775012e9
Some browsers (e.g. Firefox) change the CE range when the dialog
is opened, so after the first surfaceModel change (to modify the
internal item) the surface's selection is modified, and the reference
is inserted in the wrong place.
Bug: 52159
Change-Id: Ia5da33b95a599ba78f308cf0554279ad44616f50
Problem: When the toolbar is created twice with the same config object,
the second time around the tools are still bound to the old surface
Reason: The tool config is overwritten such that symbolic names of tools
are replaced with instances of tools, bound to a specific surface. The
second time around, the creation fails (silently in a try-catch) and then
the already translated list of tools is used to create a new toolbar
filled with old tools still bound to the wrong surface.
Solution: Leave the config object alone, and instead build a new list of
tool instances while iterating through tool names.
Bonus: Don't fail silently. Using a try-catch to detect whether a
requested tool is supported masks other errors, and is evil. Instead,
just do a lookup and skip tools in which the lookup's result is falsey.
Change-Id: Ic43ec29173e556592bb3db9399ff83787e0a6857
toDataElement part fixed in I6d496f7. This fixes the
toDomElement part so we don't trigger a round trip warning.
Bug: 51963
Change-Id: I27a7579890d669a8b980710db1bafe066b744236
This isn't a problem when using the UI buttons as they get disabled
but the command keys can still trigger these methods.
Also fix hasPastState to include check for small stack. This fixes
an existing bug where the undo button doesn't become active until
~1s after the first change is commited (i.e. after the small stack
is committed to the big stack).
Bug: 52113
Change-Id: Idbd34953c805620881a609409290256462af80a5
This commit prepares the LanguageInputWidget to handle both annotation
and node, so it can be used as the GUI for both the LanguageInspector
and the LanguageBlockInspector that's coming up.
Cleaned up the way annotations are read into LanguageInspector and
AnnotationInspector. The attributes are kept in the Widget (without regard
to what datamodel they will serve) and are then read from the inspector.
The LinkInspector had to be adjusted slightly to accomodate a small change
in the AnnotationInspector too.
Change-Id: I17954707c00ffc4c32fbb44a6807a61760ad573c
The update event passes in a transaction object, which was interpreted
as a config object and fragmented the cache. Explicitly wrap the
update() call in an event handler to make sure the config parameter is
undefined.
Change-Id: I641c68230b92d23626fb8b12aeab6a8904a35bcc
This patch rounds off change I29740fa7a by replacing calls to EventLogging's
eventLog.logEvent with calls to VisualEditor's ve.track. ve.track publishes
events by providing an interface, ve.trackRegisterHandler, which event handlers
use to subscribe to VisualEditor events. By making it the responsibility of the
web analytics framework to register itself as a handler, VisualEditor can
remain decoupled from (and indeed ignorant of) any particular event logging
implementation. This allows VisualEditor to be integrated with many different
web analytics platforms with nothing more than a bit of glue code for mapping
ve's event semantics to those of the target platform.
The practical difference that this makes is that it frees VisualEditor from
having to know about EventLogging or from having to load EventLogging
components, which means we can remove quite a lot of gnarly code. My current
plan is to migrate the code for registering and loading the 'Edit'
schema module to Extension:CoreEvents, which is also where I'll commit the
handler for VE events. (CoreEvents exists precisely to provide an organized
place for persistent but WMF-particular instrumentation.)
Once this patch is merged and deployed, the following two configuration
variables may be removed from mediawiki-config:
- $wgVisualEditorEnableSplitTest
- $wgVisualEditorEnableEventLogging
Change-Id: Idfdf692668d2adfbe029e8f0c4ff9e96c60ff741
We were assuming images were wrapped in <a> tags. Images with
link='' are only <span> wrapped.
Bug: 51963
Change-Id: I6d496f719cfbbc7556c55f0a660cb192040f29de
Add rerender event to all image loads in MWExtensioNode.
MWHieroNode's implementation of onParseSuccess is now the same as
its parent so can be deleted.
Change-Id: Iaa4999372f1ba88a7bdf1490fc3f8640af77ceae
Create getter for extensionsName which is overriden by
MWAlienExtensionNode.
Also removed angle brackets around Alien title as the inspector
already has an angle bracket icon, and a '<' close button.
Change-Id: Ice8c5d73ed621f8e585b5f372788666f8c5aeb50
onUpdate was renamed to update. Also neither event was
actually implemented so have just removed them.
Change-Id: Iaae1661a99f97272fa42c71223fc2cb832d50c66
