- User Since
- Oct 7 2014, 2:57 AM (166 w, 6 d)
- IRC Nick
- LDAP User
- MediaWiki User
Sat, Dec 16
Fri, Dec 15
No problem with accessing $menu.
Wed, Dec 13
Tue, Dec 12
@Cparle You can use the onVisible callback for adjusting any property of the ULS menu. See https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/blob/master/resources/js/ext.uls.compactlinks.js#L143 for an example. You may want to do this in your uw.UlsWidget.js
Fri, Dec 8
Wed, Dec 6
MT output is sanitized as per T169295: Sanitize MT service output HTML
Tue, Dec 5
Wrap every immediate child of body under CX section tag - For CX2 alone. Might require api versioning
Mon, Dec 4
You may also take a look at https://phabricator.wikimedia.org/T55015 and close the tickets for adding new fonts.
Webfonts feature in ULS is being reduced to languages facing missing font issues. We removed fonts for Or and other Indian languages since they don't face issue of 'missing fonts' in 2017. Because of that it is very unlikely that we add more fonts to our system.
The list of fonts which are default for one or more languages is given as a table in https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts
Mon, Nov 27
My attempts to reproduce this is failed. I tried the translation of en:The Phantom Tollbooth to he and ca languages using Chrome and Firefox. If any of you were able to reproduce, please give the langauge pair title details. Also the template if any caused the issue.
Thu, Nov 23
Nov 15 2017
Nov 13 2017
Nov 9 2017
Nov 8 2017
Since CX2 will do all of these adaptation in server, it does not make sense to have a complicated solution in CX1, the quick solution I can think of is retaining the old overlay behaviour using an option passed to the overlay widget from template editor context.
I could able to reproduce this. In case of restored translations, with templates, the templatetool tries to get the data required for the editor. That tool used to show an overlay on top of the particular template - just to avoid any action on it, till the data is available, but in https://gerrit.wikimedia.org/r/#/c/371467/ This overlays behaviour was changed to cover 100% screenwidth and height - Hence affecting the whole translation editor view.
Nov 7 2017
Should this fix work for older articles that ended up being unloadable (grey overlay when loading, the three dots on top blinking ad nauseam, publish button greyed out)? If it should - it didn't in my case.
The feature is documented in detail at https://www.mediawiki.org/wiki/Universal_Language_Selector/Compact_Language_Links
Nov 6 2017
Nov 3 2017
Nov 1 2017
I could reproduce the issue now. It was tricky.
Oct 31 2017
Oct 30 2017
Oct 27 2017
This is a regression
Oct 17 2017
Oct 12 2017
Oct 11 2017
I see this documentation about resetting 2FA https://secure.phabricator.com/book/phabricator/article/multi_factor_auth/ and apparently we have done this before (T175941: Reset Phabricator 2FA for Tgr)
We had some technical blockers to support a non wikipedia site in cxserver. We have fixed it recently T172075: PageLoader.js hardcodes wikipedia.org
Oct 10 2017
Oct 9 2017
I did some refactoring in https://gerrit.wikimedia.org/r/#/q/topic:T177752+(status:open+OR+status:merged) before addressing this task
Parsoid's patch for section wrapping https://gerrit.wikimedia.org/r/#/c/364933/
Quoting from commit message:
Since ContentTranslation (CX) currently uses <section> tags internally, to ensure that CX can distinguish between its internal use with Parsoid-provided <section> tags, we need to add a distinguishing attribute to our section tags and so this patch adds the data-section-number attribute to all <section> tags
Meta info: There is no language team now. People from old language team is under Global Collaboration team.
Oct 5 2017
Oct 3 2017
To clarify. There is a remove 2FA option at phabricator profile settings, but that also require my 2FA from Google Authenticator, which I don't have since I stopped using Google Authenticator. I have ony Authy 2FA
Sep 29 2017
Sep 28 2017
[ST] In case that machine translation is not available, null MT so that, if the user selected “source text”, the target text must be pre-filled with the (adapted) source text [0.5d, or may be working already]
It works already. Screenshot shows en-ml translation, with no MT client. Source get copied to target with all links, references adapted to target language.
Sep 27 2017
Current status: We have jquery.i18n in the core now - https://github.com/wikimedia/mediawiki/tree/master/resources/lib/jquery.i18n
And mediawiki.jqueryMsg enhances mediawiki.Messages if loaded.
https://github.com/wikimedia/language-data now provides the langauge data that was initially bundled in jquery.uls. We required this for ContentTranslation-CXserver
Sep 25 2017
In https://gerrit.wikimedia.org/r/#/c/379213/, basic autosave support implemented.
It connects the update events for the section nodes to the translation update events and do autosave. Section HTML content is extracted from the source and target
models. Some refactoring and utility method additions done for that.
Sep 20 2017
We follow the guidance from service team for this. In T170548: nodejs 6.11 the services team rolled out 6.11 as WMF production version.
Sep 15 2017
Publishing is working now with VE provided content from editor. There are some more testing I need to do for the title conflicts, overwrite warning and namespace selection. The success message banner also need some attention since it goes below the floating sticky headers