Upstream: https://github.com/wikimedia/jquery.webfonts/
Changes:
* Respect explicit font styles of child elements when switching
languages
* Fix duplicate font-weight property
Change-Id: Ic45357b2613e6f33c392f9a78cc389f31c99e036
version: v0.1.0+20131019 (commit: 4ac70e0047)
upstream: https://github.com/wikimedia/jquery.ime
Changes:
* Language tags are case insensitive now
* Fixes to Hindi and Persian input methods
* Shift modifier key support
* Misc CSS fixes
Bug: 54117
Change-Id: I581a1006c34fd86372facdae85ea48b4ed1ffc2c
Updates jquery.uls from upstream autonymfont branch
Also contains an example html page which can be used
for testing the font
Change-Id: Ia702ba1df91701df67160d973a0caaa72511c743
This patch adds a configuration variable, '$wgULSFontRepositoryBasePath', which
specifies the base path to the font repository. By default, the variable is set
to its existing value, which is $wgExtensionAssetsPath +
'/UniversalLanguageSelector/data/fontrepo/fonts/'. However, adding a discrete
configuration variable makes it possible to configure ULS to use a custom URL
scheme that is more suitable for large static assets that change infrequently.
Change-Id: Idbe57072c4f3258757eb691e54cab5429cadcfda
__DIR__ is the more common idiom these days, and there is absolutely no
advantage (in fact, there's a slight performance penalty) to storing it in a
variable. Use alternate syntax for declaring autoload classes to avoid
exceeding line length limits or having to break lines in unsightly ways.
Change-Id: I20211539ccc17937b141331c1875f219a92b1483
If not reset, the font-family will persist for languages
without font preferences
Steps to reproduce:
1. Open language settings->Display settings.
Switch language to English. Inspect the lang and font-family
of uls-display-settings element.
2. Switch language to hi. Inspect the lang and font-family
of uls-display-settings element. You can see Lohit Devanagari
as font.
3. Switch the language back to English. You can still see font
as Lohit Devanagari. With this patch, you should see font family
reset for English.
Change-Id: Ib3346d8b888c7dcfda16e8a10473c785a1ebd890
Code like $input.trigger( 'focus.ime' ); doesn't make any sense. Event
namespaces exist for binding and unbinding and are irrelevant when
triggering. However, there's a bug in the version of jQuery that we
use (1.8.3) that causes .trigger( 'focus.ime' ) to perform a native
focus and call natively bound focus handlers, but only call jQuery
event handlers bound to 'focus.ime', not handlers bound to 'focus'.
This bug is fixed in jQuery 1.9+. http://jsfiddle.net/WGy9h/3/
demonstrates this bug.
The way ULS broke VE with this went like this:
* VE initializes and creates two contentEditable divs, the
pasteTarget and the documentNode. It then focuses the documentNode.
* ULS loads jQuery.ime
* Once jQuery.ime loads, it first calls .trigger( 'focus.ime' ) on
the pasteTarget
* jQuery focuses the pasteTarget, which means a blur is emitted on the
documentNode
* In response to this blur event, VE disables the SurfaceObserver
* jQuery.ime then calls .trigger( 'focus.ime' ) on the documentNode
* jQuery focuses the documentNode, but does not call VE's focus handler
because it's bound to 'focus' rather than 'focus.ime'
* This means VE's SurfaceObserver is not reenabled
* If the user then focuses something else then focuses VE again, a
native focus event fires and the SurfaceObserver does get reenabled
Change-Id: I7c590599df4cf62418403bc1d1dccfc3c6db5fd3
