The words "Fördermitgliedschaft" and "Privatperson" cause unsightly overlaps in the summary bar on mobile. As discussed in the daily, change the mobile view (<1024 px) to show the following:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T177929 Integrate new layout | |||
| Resolved | None | T177933 become member - Integrate new layout | |||
| Resolved | None | T182098 Adapt membership summary bar to mobile |
"Fördermitglied" and "akt. Mitglied" (without line break at space)
akt. Mitglied is likely to be understood only if people read "Aktives Mitglied" several times before. Is "Aktivmitglied" an alternative?
If that’s not possible: Could I have a screenshot where the problem occured?
lets stick with Aktiv as we have Förder for Fördermitgliedschaft aswell. At least this is consistent.
Question for @Pablo-WMDE: [[ https://github.com/wmde/FundraisingFrontend/commit/5e527f83281112d079ed8794a885a0c35475e5b9 | I've extended FormDataExtractor to with the method mapFromRadioLabelsShort which can read the data-short-text attribute of labels ]]. Now I see two options for integrating the texts in the form:
I gravitate towards solution 1, but wanted to check with you.
@gabriel-wmde Am totally with 1). If I am not mistaken we are only talking about the short label in case of the summary bar which is anyways only shown on mobile, right? So we need both, the traditional and the new labels to co-exist. Or maybe I misread the question I am in favor of 2 map functions. But AFAIK we simply have to call the new one once to inject the right texts for the widget handling the summary bar.
What comes next (the view handler part) is less obvious; many options to skin that cat. So far we wanted all 4(?) widgets to behave the same way (that's what the createProxy convenience function does for us). The cleanest solution in the OO-sense would be to instantiate one of the widgets (the one for the summary bar) with the right (short) text - no need to add another property to SectionInfo. Or we could lose the - not so obvious - createProxy and do all 4(?) instantiations explicitly/manually; then we are at the right spot to inject the map from your new FormDataExtractor anyways...
In theory you could even manipulate the texts from membershipForm by talking to proxie's widget property to further configure it after construction.
WMDE.View.SectionInfo.createMembershipTypeSectionInfo(
...
).widgets[1].valueTextMap = { 'active': 'akt. Mitgl', ... } // i.e. your map function(I will stop editing this now - sorry)