Aug 18 2018
Aug 2 2018
Jun 26 2018
May 8 2018
Jan 10 2018
Oct 11 2017
We created the JSON files in l10n from Module:Project portal/wikis, naming the files based on wiki subdomains (e.g., zh-yue.json). Meanwhile, translatewiki.net lays down JSON files named for ISO 639 codes (hence yue.json). So for some languages, we have some properties in one file and some in another. Had anyone translated the strings into Literary Chinese (lzh) at translatewiki.net, we would’ve had both zh-classical.json and lzh.json for the same wiki.
The way wm-portal.js handled the Chinese localization was by baking the Traditional Chinese strings into the page, along with Simplified Chinese versions in data-convert-hans and data-converttitle-hans attributes; convertChinese() would then swap in the Simplified Chinese strings if the browser’s language was zh-hans, zh-cn, zh-sg, or zh-my.
Sep 28 2017
Sep 10 2017
@debt, that message means nothing in OpenStreetMap is tagged with the current item’s QID. The map and its overlays are provided by overpass turbo, so the gadget is unable to customize that particular message or add an edit link. It might be a different story if an overpass turbo instance were to run on Toolforge I suppose. ;-)
Sep 4 2017
Sep 3 2017
Aug 17 2017
Aug 12 2017
Change 371656 is a work in progress. In the spirit of the hackathon, I just took the quickest, hackiest path to a mostly working portal. Still to do:
Aug 10 2017
For now, I’ve implemented this feature as a user script:
Revision 1498164 adds a link to the Wikidata Query Service as a fallback:
Aug 7 2017
Jun 13 2017
Apr 10 2017
Yeah, I think the only way to respect the setting would be to use the accesskey HTML attribute or DOM property, as most of MediaWiki does. (Manually binding to hardcoded key combinations using event listeners would lead to this issue, for example.)
Apr 6 2017
Mar 21 2017
The Mapbox framework is 38MB - more than twice as large as our next largest framework - HockeySDK at 17MB.
Feb 23 2017
A query parameter would also make changes easier to review in gerrit, if I'm not mistaken.
Feb 13 2017
Words with ŠĐŽČĆ characters should be excluded. This ensures that even users who have only English keyboard can easily type the captcha.
Jan 12 2017
Oct 19 2016
Sep 26 2016
OK, that sounds reasonable. I wonder if we should try to make this new section consistent with the browser-based recommendation that goes in the top 10 ring – maybe include both browser-based and region-based languages in the new section for good measure.
Sep 23 2016
I'm a bit confused by the second mockup. Would the sections other than Recommended still be divided by article count, or would it be based on region like in the first mockup? If the latter, perhaps we could attempt to give the largest Wikipedias more prominence in the lists with a darker color or slightly larger size.
Aug 28 2016
Aug 25 2016
Aug 23 2016
Jul 24 2016
Jul 6 2016
Jul 4 2016
Sorry, I was mistaken: the Wikisource portal isn’t managed like the other portals. A Multilingual Wikisource sysop needs to update this page.
The sister project portals other than Wikisource were taken care of in https://gerrit.wikimedia.org/r/296441/, which was pulled into the site configuration in https://gerrit.wikimedia.org/r/296748/. Wikisource is managed on-wiki.
May 27 2016
iD’s maintainer was generous enough to complete and merge the PR I started. The Wikidata field will appear in the next iD release. Closing.
May 26 2016
The Vietnamese Wiktionary uses redirects for systematic variations involving diacritics, for example xoá to xóa, whereas the English Wiktionary does not. This probably doesn't show up in interwiki stats because the English Wiktionary has relatively few Vietnamese words and the French and Chinese Wiktionaries have little coverage of these variations (which affect maybe a tenth of the overall corpus). On the flip side, automatically normalizing diacritics would be problematic for the same reasons described in T78485.
May 4 2016
Jan 26 2016
Does it need to be "Search Wikipedia"? If we use the MediaWiki:Search message in translatewiki.net, we'd have full language coverage, as that message is required by the language subcommittee when requesting a new Wikipedia language.
Jan 25 2016
Indeed, the iOS apps use Translatewiki.net for localization. It's a MediaWiki installation at heart, so at the least we could use the MediaWiki API to pull down the translations.
Jan 23 2016
The proposed behavior would be simple to implement: just set the placeholder attribute on the <input>.
Jan 22 2016
CSSJanus processes the CSS stylesheet on the server side, whereas the user language is detected later on the client side. MediaWiki is able to use CSSJanus because it serves up a different stylesheet based on the uselang setting rather than the client side language setting.
Jan 19 2016
Jan 3 2016
I incorporated the <time> and Moment.js ideas into a rewrite of the CommentsInLocalTime user script that’s now installed at the Vietnamese wikis.
Dec 29 2015
We don’t run CSSJanus on the portal stylesheets, so it isn’t quite ready for RTL:
Dec 26 2015
Thanks for the mockups. For both of them, I would move the language name and article count closer to each other.
Dec 21 2015
With the Wiktionary portal, I wound up including data about the preferred logo of every wiki listed in the search menu. That compromise worked because most of the smaller wikis used the default logo anyways. A few more slogans might not hurt so much.
Dec 18 2015
Not to mention localized logos. :-) So the primary consideration would be size.
Would it look too weird to omit the slogan from minor languages that get selected? It might make sense to style these languages differently anyways. For example, see how Facebook highlights likely languages in yellow in its language selector.
Dec 12 2015
As long as the DOM manipulations happen onReady or DOMContentLoaded, they at least won't block loading the page in the first place, right?
Nov 26 2015
I mean the setting isn't easy for users to find and change. Users end up with the operating system's default language.
Correct, the page view metric came about because some wikis were gaming the system. Volapük was the most egregious case in Wikipedia, one that came up repeatedly in discussions; other projects have their own examples. Personally, I have always argued that the page view count, while fairer, was so opaque as to seem arbitrary. I field occasional requests to surface the Dutch Wikipedia in the top 10 based on article count from users who are savvy enough to find the portal's talk page on Meta. For every such user, there must be hundreds or thousands thinking alike.
Nov 25 2015
Nov 13 2015
Mind merging and deploying https://gerrit.wikimedia.org/r/252909 too? www.wikivoyage.org is still broken.
Along with the changes mentioned above, the statistics are also seriously out of date: T118544. The portals on gerrit should have been spot-checked for regressions before being deployed.
Nov 12 2015
I’ve just saved the last anticipated changes to the portals on Meta. Here are the permalinks, for reference:
Nov 11 2015
Nov 4 2015
Also, mxn's recent work does not affect the investigation phase of this work. The developers will work with him to make sure everything continues to work properly, but that work would be outside the scope of this task.
Nov 3 2015
I was hoping to clean up the Lua code a bit and document the workflow a bit better before making any noise about these changes, but I should be clear about my intentions here.
Oct 30 2015
I haven’t completed this task yet; it’s on my backlog but I’ll be getting to it eventually.
Oct 17 2015
My understanding is that the discovery team is open to making the portal a dynamic page, as I have suggested, for enabling automatic article counts. No code has been committed toward that goal, but putting the portal under Git is seen as a necessary first step. I suppose you're saying that we shouldn't cut over until the page is dynamic and fully automated, right?
Oct 9 2015
I noticed that the mockups exclude the Incubator-based language search box (currently below the first horizontal rule). Is that intentional?