That work is now being tracked under JSDoc WMF theme.

In T213292#4866792, @TBolliger wrote:

Exactly. Unless this checkbox is causing major issues and needs to be re-considered I say we keep it and move on.

Agree with @Volker_E and @Tchanders 👍🏽

@Tchanders from your previous comment I understand that its going to be tricky to add help text (tooltip, or inline) on the radio options. I wanted to ask if its going to be possible at all, or should we be thinking of other solutions?

In T202773#4855693, @Tchanders wrote:

• The existing labels haven't been changed to the labels shown in the design (e.g. "Prevent account creation" etc), because I can imagine there being some opposition to changing them.

In T210218#4858043, @Niharika wrote:

@Prtksxna We do need another design for this ticket in the event that a user directly lands on the translation page for an image using a link and the image does not have any labels for translation. In that case, we should show them the image and a message.

In T117794#4850819, @Volker_E wrote:

@Prtksxna Did you get to any start code-wise here?

In T212294#4851057, @Niharika wrote:

I've been thinking about this and its a bit tricky. A solid gray border looks odd on images that already have a border

@Prtksxna I think the number of images already having a border is really low.

In T211373#4854362, @Niharika wrote:

I like Leaflet, if that's the one you have in mind. Is that the one we're talking about?

In T210564#4836095, @Samwilson wrote:

I was imagining that the upload process would be a standard form-submission, i.e. that the browser would indicate progress, and that navigating away before it'd finished (not that it'll take very long, hopefully) would abort the process.

I think we can have the same design with different wordings. The user might get a bit confused by seeing an empty translation interface.

That makes sense @Niharika. I think that we should revise the text and sub-text though, maybe remove the links from there at least?

In T212293#4849794, @aezell wrote:

@Prtksxna I think we fixed the Docker stuff at the offsite unless it has broken again. I'll give it a try shortly and see if it's working with the current master.

In T212294#4848098, @Niharika wrote:

@Prtksxna Do we also want to add a border for images? A bunch of images have white backgrounds which can make it hard to tell how much space is available for labels until it hits the edge.

Are we able to tell the difference between images that have text that cannot be translated and images that just don't have text? Is this a special case of T210218: Show message when loading an SVG with no translations, or something completely different?

In T212293#4848081, @Niharika wrote:

@Prtksxna If you prefer, you could also directly submit PRs for minor design fixes.

That looks about right. I think the only difference left is to reduce the vertical margin of the loading indicator. On the prototype you can see the modal by going to the Event Page → Download Report → Wikidata Contributions. I think our markup is the same.

After discussing this with @jmatazzoni, here is an option that keeps the saves what we can immediately, and keeps the unsaved changes in the textarea and shows the error indicator there.

Initial	Adding new items	After hitting save

In T207776#4833168, @MusikAnimal wrote:

Sorry about that. I'm not sure what font sizes should be used, or the widths. To me it looked like Prateek's screenshots were taken when the viewport was smaller, hence the modals were too. Right now I'm using the default Bootstrap styles. I would recommend a wider modal if the viewport allows, as Bootstrap provides for us. Overriding the Bootstrap responsive design could be a bit involved, but Prateek might already have the CSS coded up.

In T210872#4835045, @Samwilson wrote:

Do you want the untranslated all lower-case like that, or with an upper-case U?

In T6995#4832856, @TBolliger wrote:

1. Yes, other field values are retained if a user switches.

👍🏽

2. Our understanding is that hide/show is not part of the supported style guide, and that active/inactive is the preferred treatment. Is this not the case?

Yep, we don't use that pattern anywhere else, was just wondering if we considered it for this. Happy to go ahead the way it is 🙂

@Samwilson, you had mentioned that we'd be able to do something like Leaflet? It'd be cool if that is possible 🙂If not we could use the ButtonGroupWidget with the + and - icons being overlaid on the image. We would also want to show the ✋mouse cursor on hover to let the user pan around.

A quick question about your comment on our doc — we'll need the upload progress state to completely block all other interactions, right?

I think we can make the text #000 here. What do yo think about the subtext, @Niharika?

Can we make a minor change in the design? Prefixing Untranslated before every label might be cumbersome for the user to read through every time. Can we move it to the bottom and make it smaller?

Yep @Samwilson's idea makes sense, let's go with that.

In T206712#4812172, @Niharika wrote:

Looks good to me! @Prtksxna take a look and we can open follow up tickets for any more design fixes we want.

Will we be able to reliably do this for different sizes of images?

In T210133#4824296, @Esanders wrote:

Why is $element not a link? I note on https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.mixin.ClippableElement that $clippable and $clippableContainer are links. Shouldn't we be fixing $element to be a link, rather than unlinking it?

In T208889#4812583, @jmatazzoni wrote:

@Prtksxna, the engineers have noted that the alignment of the help link here is not possible/standard. It will be aligned left under the Account Data left label, unless you have some better idea.

In T6995#4779710, @TBolliger wrote:

• The defaults for the pages and namespaces input fields are empty, so the default for other actions (upload, create page, etc.) should also be empty/unselected.

Thanks for your work on this, @Stibba

Hey @Sochin67, thanks for raising the ticket. Unfortunately, I am not working on this anymore, so I've added some people who might be able to help.

@MusikAnimal, is it possible to have the dropdown be wider than the input field?

Possibly happening because the fonts have been defined as HelveticaNeue-Bold, Helvetica Neue which are pre-installed on MacOS. It shows up in the default font on other OS's. Should add sans-serif here.

See also: T210349: JSDoc WMF theme: Fix JS and CSS linting issues

Thanks for posting this discussion @Volker_E and @Mooeypoo 👍🏽

In T209902#4763042, @cscott wrote:

Well, I added you as co-owner of the jsdoc-wmf-theme group. That should do it, I hope?

Thank you for working on this @Arcayn

In T208889#4763113, @Niharika wrote:

@Prtksxna I believe that's what Joe meant -

the downloadable report will be available from the "User profile" tab of Preferences

It will not be a new special page.

I guess 2000 should be fine, we can ask @Mooeypoo to test once this is done and adjust later if we feel the need 💻

In T207711#4767176, @Samwilson wrote:

I agree with both of you. Although, @Prtksxna did you mean to have different strings inside the zh and ja examples?

I just remembered that @Mooeypoo had shared that the tool becomes useless on large screens. I think we should limit the interface width to 1400px (CSS, not device pixels… retina 👀).

I don't think this means that we need to show two languages as the source language, they can still be shown as separate. If you select Chinese you get all Chinese translations, including the ones that are shared by Japanese (and the same goes if you select Japanese). And while saving if the value doesn't change we can let it be the way it is, and if it does we can split up the <text>:

Will some of these problems go away now that we are planning to T209900: Switch to using ULS as a backend for languages instead of using the ULS dialog?

In T204849#4761130, @Samwilson wrote:

The dialog also gets a scroll bar when that happens. Should we have it grow in height instead? Or start out bigger maybe?

I am guessing that we'd need to display, and allow to search using the following:

1. Language name in the UI language - अंग्रेज़ी (English, in Hindi, and written in Devanagari)
2. Language name in the language itself - English
3. Language code in latin - en

In T206495#4760904, @MusikAnimal wrote:

I took the liberty of applying the same styling changes to the other pages, just to keep them all consistent. I've got it deployed at https://eventmetrics-dev.wmflabs.org. @Prtksxna Let me know what you think! However note that the "Edit List" page is currently broken until https://github.com/wikimedia/eventmetrics/pull/143 is merged.

Does the user need to be taken to a special page to download the report? Do we know the design requirements for the Special page as well? Would it be ok to trigger the download directly from the "User profile" tab?

In T207911#4754819, @jmatazzoni wrote:

And since I am further informed that core features of this project (like the remaining four reports) are in some doubt, I can't approve that at this stage.

In T209107#4754309, @Niharika wrote:

Why a border around the Almost there... box?

Thanks for your patches @Platonides :)

@Platonides, since we won't be making the rest of the changes, would it be ok to close this task now?

In T207203#4744986, @Niharika wrote:

I like it. We should make this into a separate ticket though. We can discuss there whether this specific design is feasible to implement or not.

In T209523#4749051, @Volker_E wrote:

Meant, that workboard description and README.md of the wmf-theme differ. I would dump the workboard description and mostly only point to latter as those places got left behind until the next person is possibly frustrated.

@Volker_E Do you mind if I put this task up for GCI?

Thanks for the screenshots! The Gitlab font choice looks good. @Volker_E, is it ok if I put this task up for GCI?

Thanks for the patch @Arcayn. Looks good.

Thanks for the patch Mogmog123. Looks good.

Added a proposed design, looking for feedback 👨🏽‍💻

Some more design related stuff: