@GoranSMilovanovic no, I'll close it. Thanks btw, this was very useful.

Yes, what @kai.nissen said: The links are merely static links to the plans, they do not interact with page content (the most simple reason: it is easier to build, and probably easier to use)

@gabriel-wmde : I like the idea. I think it would create too much overhead, to create this – I do not consider the sidebar interaction wise essential, here.

Since the color changes are an easy fix for issues with our last-years best performing banner and has a rationale: Is this on any TODO-list? @kai.nissen

How is this imagined to work for our users ? e.g. imagine, a donor moved to a new place. When/Why would they change the address? Where would they go? How would they know this has been successful?

@tmletzko: This would be in a "text component" for me. After MVP state, it might make sense to give it some sort of style-class to e.g. make it "fine print" (aka a bit smaller and/or lighter) or so.

Briefly talked to @kai.nissen – here clarifications:

2.1 Q2.x are like 1.x, but only for september 2018.

Yes. Initially, you asked for an overview of the last 30 days or so. However, the wmf.mediawiki_history Hadoop table, where the data for this analysis is found, …

@GoranSMilovanovic thanks!

Wikibase and help people find all the tools and documentation around it.
People need to better understand what Wikibase is, why they'd want to use it and get answers to questions about how to install/use it.

Monserrat is not wide spread, it is not a standard font to be found in OSes standard font distribution. It is open, though, so potentially it can be installed or distributed.

I do not understand this ticket: What are concept types?

I do not entirely understand this. Is this about creating a mockup/image of a wikibase, but with some custom data in it, because an example item does not match the subject that shall be covered int he custom installation?

Is this tied to docker or should OAuth work no matter which way I install?

As a user need (as in the ticket’s body properly described) the title might be better: "easily modify the color of the theme used in an Wikibase instance". This could have the following solutions:

• Documentation
• Some sort of form where you can choose the colors (and a logo)
• Possibly different implementations for docker vs. old install

@Yurik : Thanks for pointing this out and for providing the graspable OSM example. I added the additional assessment of the usecase in the issue.

Not researched, more expert-y verdict: This should be: Adapt branding for custom installs, which usually entails choosing one or two colors (accent+ secondary), fonts and a logo. Wordpress themes often do this quite well, as do "off-label" software services.

The "root" of the problem seems to be that the frameless buttons can not be toggled. If there is no particular reason against this it seems to be the most sustainable to add toggle mode to the frameless button class (or however OOUI calls "class"/"template"…). If that is not possible for us, I would leave it as it is.

you clarified: reason for this = that I know that formerly, the payment buttons were submit buttons and I might still get stuck in this assumption.

From the point of accessibility I think the "Hoher Kontrast" is best. The "wenig Kontrast" I find problematic, since the light blue and green have a very similar brightness and offer mainly color/hue contrast rather than brightness.

@Hanna_Petruschat_WMDE
Thanks for the examples!
Could you put the font question in an extra ticket? I think it is useful to get feedback from the devs and they could work on it as a separate task, then.

@Tobias_Schumann_WMDE If that is worth the investment depends on how often people fill in the form and stop OR how often the button is clicked and yields an error.

I'm not sure to understand what you mean :)

Without a deep analysis: Revision history of "Lemma" (Q1) makes sense.
Only having the ID is problematic.

A design/tech suggestion: Define the "box" the lemma is in as wide as possible inside the UI (which follows UI-aligment). Inside this box, align content according to the appropriate alignment for the language it content is in.

Would that go through a function of some sort that renders the Word/Language combination? Or would this be defined in CSS what the sepreator is?
In any case, I have few preferences except that consistency would be great.

Could this always be done or are there case (Languages) where this would be a problem? Because if we can always pre-fill, we could just make it use the same data anyway.

It would make sense if miss-spelling would be also a selectable option (or "flag"?), as far as I understand, you need to define it manually.

1. First fix would be getting away from alphabetical sorting of numbers
2. I think that sorting by meaning (here: grammatical features) makes the most sense.

Methodological suggestion:

Which actions are these? We would need a list of problems OR try to find them ourselves, but that might not surface the relevant ones since we are no frequent editors of Lexeme.

I assume, the proposed application behaviour would fix this as well.

With the caveat that it lack the project’s background, it looks good to me.

@Jdrewniak: I also tried hugo (https://urbook.fordes.de/) and was pretty happy with it (not speaking go) – I was able to fiddle with the templates, thats a good sign :-)

Quick solution: Display an animated symbol to signal that the tool is indeed working

I looked at this UI as @Tim_WMDE told me.

Is that an API-ticket or a GUI-Ticket?

@Lea_WMDE @WMDE-Fisch : Did you (or anybody else) try out how such scaling works with a larger sample of changes? I am uncertain here – changing the scaling-the-bars-paradigm from linear to logarithmically strikes me data-viz-wise as very unusual which can indicate that this is not wide spread for a reason.

@Lucas_Werkmeister_WMDE’s suggestion seems sensible, particularly since he tried already. I see the advantage that we block on the concerning thingy, not on the save button in general.

Could I get a screenshot of the gadget/script UI, so we could have a look (I could not get it running myself right now)

@daniel do you have a list of concerns anywhere?

I think that is what T167134 is about.

@Addshore Yes, JS bit only.

@Tonina_Zhelyazkova_WMDE @kai.nissen
I guess that consistency to the non-contact-form should be there, so the color should also change on the contact form when the fields are on focus.
Rationale: 1) I see no point why it should not 2) If we keep it all constant, it is easier in the future to change widget code and design centrally since it prevents creation of solutions dependent on unusual, only-at-one-location behavior which is hard to factor out again.

I wonder – did any of the teams/people involved in this ticket make any further decisions in the last months or had success in refactoring (core?) code to enable previously difficult things in relation to MVVM Frameworks and Server Side Rendering in PHP and/or Node?

@Cirdan When testing, I noted that we do not execute the searches when a suggestion is selected, but when users press enter. since the suggestions are essential (except you know the category names by heart) it would make sense to execute the search on selection of a suggestion. Can this be done? Or was it tried and it turned out to be a bad idea?

I tried on a HD display as well on a smartphone (Moto G4) and on simulated screens in the firefox dev tools down to 280x280px and encountered no new issues due to screensize there.

Since @Tim_WMDE asked me about the blue framed box and it's content: For longer text e.g. "donation promise" via bank transfer, the text goes between the amount/payment method and the "Spendennummer" and enlarges the box by doing so.

To understand you correctly: Is "too wide" referring to the width of the left search/result column or the whole content-carrying part of the site.

@Verena @Cirdan : We have two choices here – one is going with the Wikimedia Design Style, the other is using the Wikimedia Deutschland e.V. Styleguide. The advantage of the former is that is is made to be used in a digital context, whereas the Wikimedia e.V. is stronger in print application. We could also try to mimic the campagins, but they change(d) style over time a bit and are also specific – maybe someone else wants to adapt the tool, too and then the campaign colors do not make sense – so I would suggest going with the Wikimedia Design Style

I would see the suggestions mainly as a way to understand how the tool works – it is highly unlikely that a suggestion matches a special interest of the user (particularly for long, detailed category names). Thus, it is not essential to have a full name. We could either discard too-long-categories or we shorten them with an ellipsis (max-width and text-overflow: ellipsis; ). Bonus, if the title attribute has the full name, still, since it appears on hover in browsers.

What is meaningful to track depends on our concerns. I assume for now, it is

I like the idea. I would not do this via color due to accessibility and style reasons (quickly looks "too confetti"). The most solid seems for me to just add "schwierig:" or "einfach:" in front of the badges – something like this: