Template talk:Community Wishlist Survey/styles.css

Rtl

@MusikAnimal (WMF) (Not following what the actual issues are, just noticed your edit summary.) IIRC, TemplateStyles runs CSSJanus on the CSS for RTL. A rule or set of rules can be set to have CSSJanus ignore them by adding a /* @noflip */ comment (assuming I'm remembering correctly). --Yair rand (talk) 23:29, 3 January 2022 (UTC)

@Yair rand Ah, that would explain the auto-magic I was imagining must exist! Thank you for clarifying :) I will try to the noflip trick for that particular problem.

There is a bigger problem that perhaps you can help me with as well. We can't use the translate extension on every page because some content like votes and comments must be shown immediately (and not after the page is re-marked for translation so the bot copies over content to the lang subpages). This isn't really a problem thanks to translation-aware transclusions (see the Spanish example), except for RTL languages. While everything gets translated as it should, the direction is still LTR because the page language is EN, and .mw-body-content gets .mw-content-ltr which adds direction: ltr;. For instance, when viewing a category page in Hebrew, the proposal section headings and the bullet points, etc., are floated to the left when they should be right. What is the normal way of handling this issue (without using the Translate extension)?

I thought about using .rtl * { direction: rtl } but that didn't work because TemplateStyles prefixes everything with .mw-parser-ouput. So my next idea was for the category header template to have an un-closed tag like <div class="{{dir|{{int:lang}}|rtl|ltr}}"> so that the rest of the content on the page can be styled with .rtl { direction: rtl }. Does that sound reasonable? I believe however with an un-closed div tag, mw:Talk pages project/Replying will break, but I haven't tested this theory yet. Thanks for any help you can provide! MusikAnimal (WMF) (talk) 23:46, 3 January 2022 (UTC)

Well, my idea seemed to work, but indeed it does break the Reply tool. I don't know if that's a deal-breaker or not. RTL users will have to edit the source manually, but maybe that's for the best because I believe we also typically want to wrap RTL text in code that sets the direction.

Or maybe all of this is a bad idea, and we should just accept that RTL readers will see things aligned LTR. They still get the translations, at least.

I'm a bit torn! MusikAnimal (WMF) (talk) 00:22, 4 January 2022 (UTC)

I think I've found a happy medium of applying direction: rtl only to areas we know benefit from it, such as Template:Community Wishlist Survey/Proposal. The whole page probably shouldn't be RTL because it makes any LTR comments hard to read (no indentation on replies, for instance). Anyways if you have any input please of course share, but unless someone tells me otherwise I'm going to assume this is an acceptable approach. MusikAnimal (WMF) (talk) 00:36, 4 January 2022 (UTC)

I don’t exactly understand what you want, but generally you shouldn’t blindly add direction: rtl to pages, as you can’t rely on content actually having been translated. (I usually try Egyptian Arabic (arz) or Sindhi (sd) when I want to see how an untranslated page looks like in a right-to-left language, as these languages rarely have translations). Instead, templates that are translated should indicate this in the output: for example, Template:Community Wishlist Survey/Proposal header/Support button/he outputs <bdi lang="he" class="mw-ui-button mw-ui-progressive wp-addme-button user-show" role="button" data-addme-proposal="Proposal+header%2FProposal+page">בעד</bdi>; the <bdi> element explicitly instructs the browser to ignore the context and determine the text directionality only based on the element’s content. (This works well with this one-translation unit template, but HTML’s directionality determination algorithm fails for partially translated pages, so in that case, it’s better to explicitly include a dir HTML attribute (and not CSS property!, so that non-CSS-capable browsers and probably other non-browser software also benefit from it), determined using the {{dir}} template. —Tacsipacsi (talk) 17:36, 5 January 2022 (UTC)