mcdevitd wrote:

Sorry, that's https://commons.wikimedia.org/wiki/File:Sketch_map_of_Metlakahtla_Annette_Island,_Alaska,_to_show_the_part_seized_by_the_misson._From,_Metlakahtla_case._A...._-_NARA_-_298063.jpg

I don't think solving this is worth this much as the effort of creating a library for parsing/representing/displaying partial dates. Wikidata will support date precision, so once we switch to that, such cases will be easy to handle; how to import partial dates correctly into Wikidata is another matter.

This may have been solved with https://gerrit.wikimedia.org/r/92298 - can someone confirm that it's still an issue?

moment.js does not support partial dates (it will parse them, set all missing fields to zero and then handle them as exact dates). I looked for partial date libraries but didn't find a decent one for either JS or PHP. As I said, I don't think this would be worth the effort.

Although the image mentioned in T89108 has a <time> tag, so it is machine-readable, with a lengthy specification at https://html.spec.whatwg.org/multipage/infrastructure.html#dates-and-times ... this should probably be upstreamed to moment.js.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

@Jc86035: If you'd like to dig, see https://momentjs.com/docs/ and https://github.com/moment/moment/issues .
And I don't see why the task priority was increased.

I agree this is confusing for end-users. Can anyone point me to a tutorial for changing Wikimedia Viewer content with userland Javascript?

There is no such tutorial. There is general information about the MultimediaViewer codebase and programming in JavaScript though. :)

Would it be possible on the Media Viewer side to call different moment() functions (to reduce the specificity) if the string contains fewer than two delimiters (treating double spaces, etc., as one delimiter)?

I looked at this for a bit. I cannot do any fixes client-side, except perhaps some temporary hack which would introduce risk anyway.

If I worked for Wikimedia and were making this change, I would edit Moment.js to record the precision of the parsed datetime and attach it to the object in a retrievable way. This involves pushing changes upstream (or, perhaps forking the project). Then, use this precision to output the data in the Mediaviewer.

I've gone a bit through the issues in moment's bug tracker, and the reason they don't have this as a native property, is because the javascript dates don't have this (everything is unixtime related). Adding something like it could complicate calculations etc. which is not desirable.

However. When you create a moment date, you can do it like this:
moment('your date').parsingFlags().parsedDateParts
And then parsedDateParts is an array of recognised date parts in descending order.. From that we should be able to derive the precision, and then adapt the output format according to that precision as well.

We only need an exception for years and one for year/months, so that seems achievable.

> moment('1926-02').parsingFlags().parsedDateParts
< [1926, 1] (2)

Interestingly, it has a bug for years it seems..

> moment('1926').parsingFlags().parsedDateParts
< [] (0)

But isValid() is still true there, so I guess we can make assumptions in that case. I've filed a ticket about this problem.

@TheDJ more generally, they should probably support the syntax recognized by <time>.

Salutations, I'm [[User: Zanygenius]]. I plan to make more constructive edits to the phabricator, however I need a foundational edit. I didn't know where to begin, so when a user asked for someone to copy their comments to this task, I knew it would be right. So,

:When the source description page gives only a month or year, e.g. only "July 2010", or only "2010", the Media Viewer is STILL incorrectly showing the date as the first of the month. This was raised months or even years ago, and seems to have incorrectly been given a "never bother to fix" priority. Showing a spurious "1st" date is just WRONG. It needs to be FIXED. (Copied from https://en.wikipedia.org/wiki/Special:Contributions/86.191.166.249 's comment).

In other words (s/he?) would like to hide the dating if the parameters say so. Could you help? See conversation here: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&diff=next&oldid=821518974#Media_Viewer_still_showing_incorrect_dates_on_photographs

@Zanygenius those comments do not add any new information. Next time you don't have to add such comments, they do not contribute to solving the problem.

Okay then, I'll keep in mind. I have figured that maybe you would have suggestions for this if I asked, but know I know to try to re-word them. Have a good day,

The Community Wishlist Survey is a good place for promoting problems that you consider under-prioritized (although it was just finished so you'll have to wait a year for the next one). Or you can try to explain the relevant product owner why do you think this task is more important then everything else they are planning to work on (how many images does it affect? how many views does it affect? what problems does it cause to the reader who is exposed to it? etc.) There are hundreds of open multimedia tasks, and for any given one you can find a user who feels strongly enough about it to write "wrong" in all caps, that's just not useful input for prioritization.

Change 992792 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/MultimediaViewer@master] formatDate: handle year, handle <div>

https://gerrit.wikimedia.org/r/992792

[suggestion] I'm now seeing the following:

Could we make that say:

Created: 1926

Change 992792 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] formatDate: handle year, handle <div>

https://gerrit.wikimedia.org/r/992792