Delete *all* translations and start over, but then there’s a lot of extra work that didn’t need to happen

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.

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.

Duplicate of T313257.

In T180345#7624467, @mxn wrote:

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:

phở: 𬖾, 頗
râu: 鬍, 𩅺, 𩭶, 𩯁

In T236593#8026331, @mxn wrote:

If it is so important that forms not be used for orthographic variants of a non-alphabetic writing system, then the alternative approach would be to store the quốc ngữ and chữ Nôm representations in separate lexemes, as though they’re different languages. We could link individual quốc ngữ and chữ Nôm senses together as translations. This would be broadly consistent with the approach taken on every Wiktionary and render this ticket moot for Vietnamese, but it bends the definition of a language quite a bit.

In T236593#8025472, @AGutman-WMF wrote:

@mxn If these are purely orthographic variants (i.e. the pronunciation is the same) I would list them under a single lexeme. And in that case, the most natural way would be to list them as spelling variants rather than distinct forms.

In T236593#8017255, @mxn wrote:

In T236593#8015993, @AGutman-WMF wrote:

The ideal solution would be to allow (in the language code validator) arbitrary language codes including a rank identifier. For instance, for Viatnamese one should be able to use codes such as vi-x-Q8201-1, vi-x-Q8201-2 etc. Currently this doesn't pass the validation as one gets the error Invalid Item ID "Q8201-1".

It sounds like representations need the ability to have qualifiers…

In T236593#8015993, @AGutman-WMF wrote:

The ideal solution would be to allow (in the language code validator) arbitrary language codes including a rank identifier. For instance, for Viatnamese one should be able to use codes such as vi-x-Q8201-1, vi-x-Q8201-2 etc. Currently this doesn't pass the validation as one gets the error Invalid Item ID "Q8201-1".

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.

In T180345#7916710, @C933103 wrote:

In T180345#7916540, @GerardM wrote:

So what is the font to be
used?

Please see this list of fonts: https://en.m.wikipedia.org/wiki/Template:Vi-nom/fonts.css

In T180345#7916018, @Yellowtailshark wrote:

In other words, "vi-Hani" should refer to Hán tự/Hanzi. A person reading Classical Chinese should be able to discern its meaning and not really notice the source is from Vietnam.

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.

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.

This change should be communicated on wiktionary village pump

In T181319#7788961, @Manuel wrote:

Note from Wikidata Data Re-use Days: @Mike_Peel Q says some Items are huge (e.g. 4.3MB for Q87483673). This is problematic! @Mahir256 noted that this task might be a solution.

In T289972#7735847, @Jdrewniak wrote:

There are only search options for wikis with 100,000+ articles, of which Santali is not one yet. This range is somewhat arbitrary and I think it can be changed, maybe to include wikis with 10,000+ articles instead.

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

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:

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.

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.

This template implements a workaround using the CSS border-radius property, though built-in support would be much more semantically correct.

See step 4 on https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes#How_to_request_a_change :-)

In T238417#6847374, @Jarekt wrote:

Disadvantages:

• each tweek of one of the languages is a code change. If a function is used on 70M pages (as some did) than 70M pages need to be updated.
• moving the code to different wiki requires you to also copy i18n tables, resulting in dozens of out of synch translation tables.

• Is the original artwork for the water waves available?
  • https://github.com/kartotherian/osm-bright.tm2/blob/master/pattern/wave.png

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

In T286863#7224685, @Aklapper wrote:

Looking at https://vi.wikipedia.org/wiki/Đặc_biệt:GadgetUsage , this seems to be a default gadget (so we have no idea how many people use it?).
https://vi.wikipedia.org/wiki/MediaWiki:Gadget-AVIM.js and https://vi.wikipedia.org/wiki/MediaWiki:Gadget-AVIM_portlet.js imply it is some 13 year old "Vietnamese Input Method". It would help a lot to know/understand if modern operating systems have solved some/most/all of what this gadget offers, and potentially disable it?

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.

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.