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:

The answer has two parts

As for now, I would attach the * to the labels for required fields, even if that is a problem for the "placeholder-labels" in the new skin.

If we want people to use the form we should make it as easy as possible to use it. Thus we should have as few mandatory inputs as possible. It depends on the way such requests are managed which data is essential.

I would not put email in the "anonymous" part, since it is a "hacky" solution and thus hard to maintain and redesign in the future

I second Charlie here but want to highlight that the labels are indeed quite long due to their "Nominalstil". Kai’s change is in my opinion in the right direction, but it should actually be a UX, or better, a writer's job to go over the texts and make them terse and graspable.

Thanks! What I could use for the specs/design example is the linked coodepen which Pau created 4 years ago and on which I build a slight color change as suggested by you in the ticket comment.

@Volker_E Did the "moving dots" from T165286 get added to OOUI or component-ized otherwise?
I want to avoid to create another animation most likely not exactly able matching T165286.

I briefly talked to @gabriel-wmde. For the entry field, it would make sense design and code wise if the custom €-being-inserted-directly-after-number would be used and be consistent between the var/ctrl.