管理バックエンドのテーマを無視するか、<html>にクラス名を追加するか?

Different theme for admin backend? の議論の続きです:

管理 UI のテーマ化を回避するための現在の推奨ワークアラウンドは以下の通りです:

Discourse は SCSS をサポートしているため、テーマに body:not(.admin-interface)一度だけ追加すれば十分です。すべてのルールに追加する必要はありません。

一見すると問題がありそうです。なぜなら、さまざまな色が定義されている :root セレクターが <body> よりもにあり、カスタムカラーが依然として管理インターフェースとユーザーインターフェースの両方に影響を与えるからです。

もし <html> タグにも .admin-interface(またはそのバリエーション)クラスが付いていれば、もっと簡単だったでしょう。(あるいは、より理想的には、管理 UI 用に別(デフォルト)のテーマを構成できるようにすれば、テーマのカスタマイズがさらに楽になります。)

もし Discourse がテーマ作成者が通常ユーザーにしか表示されない部分だけをテーマ化できるようにすれば、テーマの作成やカスタマイズが容易になるでしょう。


少し関連する話題として、管理 UI で別の言語を使用することがあります(ここで議論されています:https://meta.discourse.org/t/can-discourse-have-different-language-interfaces-for-admin-only/173560)。これは、非常に不正確(つまり誤っている)または不完全(多くの文字列が未翻訳)な言語の翻訳を調整する際に特に役立ちます。

現在、エストニア語で Discourse をセットアップしており、問題のあるユーザー向け翻訳をその都度修正したいと考えています。しかし、エストニア語の管理 UI は、多くのテキストが誤っていたり、単に理解不能であったりするため、非常に混乱を招きます。

「いいね!」 2

はい、ある時点で管理エリアを分離するのは理にかなっていると思います。それは通常不要なテーマ作成の負担を増やす可能性があります。WordPress も管理画面のテーマやスタイルを分離しています。

その間、HTML タグに admin-area クラスを追加する PR を作成しました。既存のテーマに影響を与えないよう、別の名前を使用し、古い body タグも残しています。

「いいね!」 6