User Details
- User Since
- Oct 7 2014, 6:23 AM (333 w, 1 d)
- Availability
- Available
- IRC Nick
- MinhNguyen
- LDAP User
- Mxn
- MediaWiki User
- Mxn [ Global Accounts ]
Dec 26 2020
Dec 24 2020
Dec 22 2020
Adding chữ Nôm would be a nice improvement for Vietnamese-language Wikimedia projects as well as for federated projects. For example, an infobox at the Vietnamese Wikipedia could display the historical chữ Nôm name of a place or person. OpenStreetMap currently has a nonnegligible number of chữ Nôm names, even though the project is supposed to focus on current details rather than historical details. It’s likely that the people who contributed these names would be less likely to add them to OSM if they were able to add them to Wikidata, where historical nuances could be better accounted for (like the distinction between Ho Chi Minh City and Saigon).
Dec 9 2020
This would also be useful for adding a basic visualization of the data for some kinds of tabular data. For example, many of the Data talk: pages in https://commons.wikimedia.org/wiki/Category:Tabular_data_of_COVID-19_cases contain time series graphs of the case tables.
As an example of how this feature would be useful on Wikimedia wikis, https://commons.wikimedia.org/wiki/Category:Tabular_data_of_COVID-19_cases is populated entirely by pages in the Data talk: namespace because it isn’t possible to add the data tables directly to the category.
Oct 31 2020
Wikimedia Maps appears to be pretty much caught up now, based on some spot checks of recent edits I’ve made to OpenStreetMap. For example, https://www.openstreetmap.org/changeset/93204365 added a covered bridge and creek that show up in https://maps.wikimedia.org/#19/39.71640/-81.61655.
For what it’s worth, the relation I reported in https://phabricator.wikimedia.org/T218097#6007413 has begun showing up in mapframes, so something has begun moving, though I don’t know if Wikimedia Maps is fully caught up.
May 25 2020
May 21 2020
I think that would require a WDS query on every page load, which would spare one API by hammering another. 😉
While not perfect, the Overpass user script does enable users to see which OpenStreetMap features are linked to the Wikidata item. (This is distinct from P625, which is about coordinates rather than OSM features.) The original idea at the hackathon was to have this functionality incorporated into Wikidata as a gadget, so I’ll leave this issue open.
May 11 2020
One strategy I often see in table editors (both on the Web and on native platforms) is to maintain only a single input field and move it around to cover the selected cell. (On Apple platforms, this is called the “field editor”.) Unselected cells are otherwise just plain text. That keeps things lightweight even for large tables and makes it more straightforward to swap in other kinds of input fields depending on the data type.
May 10 2020
T63989 implemented an editing interface for PageForms using jsGrid, which seems suitable for editing the data inside tabular data inline, if not the structure too.
Should we try to unify the functionality in https://en.wikipedia.org/wiki/Template:Json2table and https://en.wikipedia.org/wiki/Module:Tabular_data? Or maybe it’s better to have one focus on “raw” output and the other focus on polished formatting?
@eprodromou had a similar idea with https://en.wikipedia.org/wiki/Module:Covid19Data, which is specific to COVID-19 case count tables. (https://en.wikipedia.org/wiki/Template:Medical_cases_chart can also display such a table as a bar chart.)
This is now one of the functions in https://en.wikipedia.org/wiki/Module:Tabular_data. For this function to be useful to articles that currently hardcode tabular data, there will probably need to be styling and data formatting options, and the sources should probably go in <ref>.
May 9 2020
mw.ext.data.get() returns the tabular data for a page as a Lua table. A starting point would be to output a wikitable that formats the tabular data exactly as on Commons.
Mar 28 2020
https://maps.wikimedia.org/geoshape?getgeojson=1&ids=Q1783171 returns nothing despite https://www.openstreetmap.org/relation/9795457 having been tagged a few days ago in https://www.openstreetmap.org/changeset/82619979 .
Jan 31 2020
When the Wikipedia portal was modernized in 2016, the intent was that all the sister portals would get a similar facelift and upgrade. However, the Foundation could only commit resources to modernizing the Wikipedia portal, and there didn’t seem to be much traction on the rest.
Nov 2 2019
Jan 2 2019
What is the exact failure? At which exact step?
Jan 1 2019
Nov 28 2018
Aug 18 2018
Aug 2 2018
Jun 26 2018
May 8 2018
Jan 10 2018
This proposal would add Wikidata links to taginfo pages as well, based on the links in the infoboxes on the OSM Wiki.
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()](https://phabricator.wikimedia.org/diffusion/WPOR/browse/master/dev/wikipedia.org/assets/js/wm-portal.js;66831d2a556c51b52344454108129c8bcf286829$116) 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
Aug 17 2017
At Wikimania, @Halfak wrote up some notes about revscoring’s current architecture and how it could be modified to accommodate OpenStreetMap changesets and features.
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:
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
Just to be clear, T143126 was about the direction within an RTL link box, regardless of the user's language, whereas this task was originally about the orientation of all the link boxes when the user's language is RTL. The two could of course be taken care of together, one with CSS and the other with JavaScript.
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
Thanks!
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.
This was taken care of in https://gerrit.wikimedia.org/r/296441/, which was pulled into the site configuration in https://gerrit.wikimedia.org/r/296748/.
This was taken care of in https://gerrit.wikimedia.org/r/296441/, which was pulled into the site configuration in https://gerrit.wikimedia.org/r/296748/.
This was taken care of in https://gerrit.wikimedia.org/r/296441/, which was pulled into the site configuration in https://gerrit.wikimedia.org/r/296748/.
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
Theoretically we could write some JavaScript to flip the interface ourselves based on the detected language, but the page flipping would likely be quite distracting for visitors.
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.
That's not a bad idea! Perhaps the markup would contain the English slogan for the benefit of users without JavaScript enabled, then localize the slogan as soon as possible. What if the user's language isn't one we have a slogan for, though? Should we leave a blank space so as not to appear anglocentric?
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 13 2015
Mind merging and deploying https://gerrit.wikimedia.org/r/252909 too? www.wikivoyage.org is still broken.