In T218097#6711984, @Madalino wrote:

Hi
I've found a link without data https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q34600 despite https://www.openstreetmap.org/relation/357794 have been tagged more than 3 years ago https://www.openstreetmap.org/relation/357794 ¿I don't undertand?

In T180345#6710271, @Nikki wrote:

I think it would be useful to see some examples of how these would be used/what they would be used for.

I'm not sure that ko-kore (or ko-hani) would be the best way to add text containing hanja because wouldn't we want it to be linked to the corresponding hangul? Years ago, I proposed a "hanja" property for Korean (proposal here) . It was rejected at the time but I still think that would be the best way to do it and perhaps it would be a good idea to revisit it.

I imagine it's a similar situation for vi-hani.

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).

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.

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.

In T218097#6007413, @mxn wrote:

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 .

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.

In T173052#6161088, @Pigsonthewing wrote:

In T173052#6154762, @mxn wrote:

In T173052#6154753, @Pigsonthewing wrote:

We could significantly reduce the number of API calls by not having the script query overpass for certain classes of item (instances of human, taxon, academic paper, astronomical object, language, genome, chemical compound, etc.)

If the map display could also not appear for those classes, so much the better.

I think that would require a WDS query on every page load, which would spare one API by hammering another.

Would it? I'm no coder, but I would have thought the script can read the content of the page on which it occurs.

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.

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.

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>.

An attempt: https://en.wikipedia.org/wiki/Module:Sandbox/Mxn/Tabular_data

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.

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 .

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.

What is the exact failure? At which exact step?

In T171374#4122276, @MusikAnimal wrote:

I'm going to take another stab at this tomorrow. I still think it's a race condition, where CodeMirror's keypress event is getting fired first. Maybe we could introduce a "hook", so to speak, that IME could use? This would mean modifying the core codemirror.js, but it seems something like this might be worth committing upstream anyway. Other editing libraries that work off of keypress might have the same issue.

This proposal would add Wikidata links to taginfo pages as well, based on the links in the infoboxes on the OSM Wiki.

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.

@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. ;-)

At Wikimania, @Halfak wrote up some notes about revscoring’s current architecture and how it could be modified to accommodate OpenStreetMap changesets and features.

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:

For now, I’ve implemented this feature as a user script:

Revision 1498164 adds a link to the Wikidata Query Service as a fallback:

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.)

The Mapbox framework is 38MB - more than twice as large as our next largest framework - HockeySDK at 17MB.

A query parameter would also make changes easier to review in gerrit, if I'm not mistaken.

Words with ŠĐŽČĆ characters should be excluded. This ensures that even users who have only English keyboard can easily type the captcha.

In T147656#2728114, @Lydia_Pintscher wrote:

In T147656#2727633, @Psychoslave wrote:

Will it be all interwiki links, including for Example translations section, or only mostly identical lexemes (or any other identification unit set)?

Can you show me an example of a translation section?

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.

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.

In T65216#653257, @Nikola_Smolenski wrote:

A possibility is to simply avoid words with diacritics, which should be possible for most languages.

In T353#2427687, @Yair_rand wrote:

Note: I submitted a change to the Node.js version of CSSJanus on github a while back, implementing vertical writing support.

Thanks!

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.

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.

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.

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.

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.

The proposed behavior would be simple to implement: just set the placeholder attribute on the <input>.

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?

I incorporated the <time> and Moment.js ideas into a rewrite of the CommentsInLocalTime user script that’s now installed at the Vietnamese wikis.

We don’t run CSSJanus on the portal stylesheets, so it isn’t quite ready for RTL:

Thanks for the mockups. For both of them, I would move the language name and article count closer to each other.

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.

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.

As long as the DOM manipulations happen onReady or DOMContentLoaded, they at least won't block loading the page in the first place, right?

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.

Mind merging and deploying https://gerrit.wikimedia.org/r/252909 too? www.wikivoyage.org is still broken.

In T117515#1803178, @Nemo_bis wrote:

Last anticipated changes?