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() 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?

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.

I’ve just saved the last anticipated changes to the portals on Meta. Here are the permalinks, for reference:

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.

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.

I haven’t completed this task yet; it’s on my backlog but I’ll be getting to it eventually.

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?

I noticed that the mockups exclude the Incubator-based language search box (currently below the first horizontal rule). Is that intentional?

Deployed. Thanks for your patience!

@Krinkle, Mys 721tx, @PiRSquared17, @MZMcBride, and @MF-Warburg have all filled in for me during my past wikivacations. Since this change would affect the scope of Meta adminship, I’ve posted to Babel explaining the proposal and soliciting comments.

Now that 239987 has been merged (based on [[m:Special:PermanentLink/13619906]]), does that mean changes need to be pushed there from now on? Or when does the cutover happen? We’re nearing a major milestone (5M articles at en:), so we need to make sure both the portals and the Meta documentation get updated.