User Details
- User Since
- Oct 7 2014, 6:23 AM (469 w, 9 h)
- Availability
- Available
- IRC Nick
- MinhNguyen
- LDAP User
- Mxn
- MediaWiki User
- Mxn [ Global Accounts ]
Aug 31 2023
Aug 29 2023
Apr 9 2023
The sparse FAQ about rel="me" made it sound like it’s purely about whether the two pages represent the same entity, but this documentation does emphasize the need to make identity consolidation an opt-in, which the feature requested here definitely would not be. I’d be OK with closing this issue unless there’s some way to make the linking more nuanced.
Apr 8 2023
Aug 31 2022
Delete *all* translations and start over, but then there’s a lot of extra work that didn’t need to happen
Aug 10 2022
This issue still affects any language that numbers its months instead of naming them. Chinese, Japanese, Korean, and Portuguese have been mentioned above, to which I’d add Vietnamese. These languages have narrow month “names” that are just bare numbers and instead rely on date formats to append a prefix or suffix to the month name.
Aug 4 2022
The approach I had to take with Vietnamese (separate lexemes per word per writing system, “translations” from one writing system to another) does have some downsides. For one thing, the criteria for a translation between vi and vi-Hani must be stricter than the criteria for a translation between vi and en; otherwise there would be no way to distinguish these transcriptions from translations more generally. In principle, it would follow that every simplified Chinese character should also have a separate lexeme from the corresponding traditional character(s), as on Wiktionary, and we could even take this to the extreme that “colour” is the en-GB “translation” of “color” in en-US. Maybe this wouldn’t be such a slippery slope with a dedicated “transcriptions” or “readings” property alongside the “translations” property, but such a property would be less discoverable by data consumers.
Jul 31 2022
Jul 19 2022
Duplicate of T313257.
Jun 27 2022
Jun 24 2022
Jun 21 2022
Nearly Vietnamese lexeme would be affected by this issue, because one of the two writing systems for the language is phonetic while the other is phonosemantic, resulting in a many-to-many relationship between the two writing systems.
May 10 2022
Apr 30 2022
I agree that zh-classical shouldn’t be included in the conversion feature, since no browser or operating system would come with a Classical Chinese localization anyways.
Apr 14 2022
The OpenStreetMap Wiki possibly saw this issue as well at one point, but then it went away. It was only affecting the mr, pam, and tl localizations there.
Mar 25 2022
This change should be communicated on wiktionary village pump
Mar 18 2022
Mar 5 2022
Feb 7 2022
Belatedly unassigning myself, since I got distracted away from this task a long, long time ago. But the good news is that @Bharatkhatri351 is actively working on modernizing this portal as part of T286437 and related tasks. (Feel free to claim this task if you think everything it covers is within the scope of your project.)
Jan 16 2022
Wikidata’s Vietnamese-language lexemes are currently using vi-x-Q8201 as the language code for chữ Nôm, as a workaround for this issue:
Dec 17 2021
Future deployments based on the table above should note that there’s a potential for naming conflicts that is already causing some wikis to be branded with the wrong site’s wordmark: T296501.
This affects the logo at the top of every page at the Vietnamese Wikibooks, either when using the mobile interface or when using the new Vector skin. It’s very confusing for readers to see the site branded with another site’s wordmark.
Dec 9 2021
This is also affecting the Vietnamese Wikibooks. Contrary to the table in T290091, rOMWCbf82bfb3ddcaff04a1e90abc435ccb26f792780c uploaded only a single en-wordmark.svg and used it for the French Wikiquote, Vietnamese Wikibooks, Outreach, and Strategy wikis.
Nov 16 2021
This template implements a workaround using the CSS border-radius property, though built-in support would be much more semantically correct.
Sep 22 2021
Aug 31 2021
Aug 27 2021
Aug 21 2021
- Is the original artwork for the water waves available?
Aug 17 2021
As noted in T286863#7287345, @MikePlantilla has begun work on a jquery.ime-based reimplementation of Vietnamese IME.
Thanks @MikePlantilla, that looks promising indeed! I look forward to taking the implementation for a spin. Let’s continue the conversation over in T65465.
This change fixes the errors reported above by synthesizing an input method, based on this change in an old version of the AVIM Firefox extension. I tested it in Firefox 56, Firefox 91, Chrome 94, and Safari 13.1 while logged in. (I don’t know of a way to test the new Vector improvements while logged out.)
Aug 16 2021
Aug 5 2021
That’s fair. The main thing we miss out on with the existing DPL extension is the ability to apply styling per language, since each link title could be in a different language with different font needs. But we’ve been making do for years, so it isn’t a huge issue for us.
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: