Probleme mit dem Webfont für die äthiopische Schrift

Beim Nachrüsten der Äthiopien- und Eritrea-Artikel mit {{Lang}} ist mir aufgefallen, dass der Webfont für die äthiopische Schrift nur bei {{lang|am|…}} und {{lang|ti|…}} (Amharisch und Tigrinya) geladen wird, bei {{lang|gez|…}} (Ge'ez (Sprache)) und {{lang|tig|…}} (Tigre (Sprache)) sowie bei den kleinen äthiosemitischen Sprachen wie Harari (har), Silt’e (Sprache) (stv) und Zay (Sprache) (zwa) funktioniert es nicht (zumindest nicht im Firefox). Die zusätzlichen Sprachauszeichnungen kommen hierzuwiki hauptsächlich für die Sprachartikel selber in Frage, aber auch der Artikel Äthiopischer Kalender wäre eventuell ein Kandidat für {{lang|gez|…}} (falls die Angaben nicht in Wirklichkeit, wie von mir provisorisch angenommen, amharisch sind). Gibt es vielleicht einen zügigen Weg, das Verhalten zu ändern? Beim Webfont für die tibetische Schrift funktioniert (im Firefox) übrigens nur {{lang|bo|…}}, aber nicht {{lang|bo-Tibt|…}}. -- Olaf Studt (Diskussion) 12:21, 4. Aug. 2013 (CEST)

Bei den Kambodscha-Artikeln habe ich dann noch festgestellt, dass der Mechanismus (entgegen den Vorgaben des W3C) case sensitive ist: {{lang|km|…}} funktioniert, {{lang|Km|…}} dagegen nicht. -- Olaf Studt (Diskussion) 00:03, 5. Aug. 2013 (CEST)


  • Beim beeindruckenden Repertoire deines Sprachverständnisses wirst du auch Englisch können.
    • Probier mal die Disku zu mw:Universal Language Selector.
    • Das ist angenehmer als auf Bugzilla; und dort allerlei Konfigurations- und Kategorisierungsregeln zu beherzigen, dann direkt mit Entwicklern einen auf konkreten technischen Einzelheiten basierenden Dialog zu führen.
  • Die technische Organisation kannst du hier durchstöbern: mediawiki/extensions/UniversalLanguageSelector/*.
    • Die für das von dir angesprochene Problem maßgebliche Liste von Codes habe ich heute morgen bei einer kurzen Durchsicht allerdings nicht gefunden.
    • Es könnte sogar sein, dass eine solch detaillierte Zuordnungstabelle, die Gemeinsamkeiten um Sprachen und dazu verwendeter Schriften verknüpfen würde, noch gar nicht existiert.
    • Die momentane Realisierung scheint mir sehr viel simpler: Aus dem elementaren Code einen Font, alles andere bleibt Latein.
  • Ich vermute mal, man hat es unterlassen, alle ankommenden Codes konsequent in Kleinschreibung zu überführen. Das würde deine Beobachtung bei Km erklären.
  • Um gez einer grundsätzlich anderen Schrift-/Sprachenbezeichnung zuzuordnen, wird man sowas wie einen Alias brauchen. Das kommt häufiger vor.
  • In den meisten Fällen wäre die Hauptform vor einem Bindestrich eine gute Rückfallposition (fallback), wenn die Untervariante nicht eigenständig definiert ist.
    • Das trifft nicht immer zu; sr-ec und sr-el wären explizit auf ru und la abzubilden, aber de-lb kann auf de zurückfallen, falls unbekannt.
    • Eine solchen zweiten Versuch habe ich beim Überfliegen nicht gesehen.
    • bo-Tibt ist mir nirgends aufgefallen.
  • Eine textuelle globale Beschreibung zur angewandten Methodik und Konzeption oder den groben Abläufen (gerade in den von mir thematisierten Aspekten) habe ich nicht finden können. Es wird halt irgendwie gemacht, und dann ist es passiert. Die FAQ geben nur die Bedienungsanleitung für das Gadget wieder.
  • Ich habe die Programmierung heute morgen nur flüchtig durchgescrollt; es könnte sein, dass deine Sprachkenntnisses eine wertvolle Bereicherung zur Konzeption liefern.
LG --PerfektesChaos 09:37, 5. Aug. 2013 (CEST)
Danke für den Hinweis, welche MediaWiki-Seite zuständig ist. Ich habe meine Anfrage dort auf Englisch wiederholt. -- Olaf Studt (Diskussion) 11:16, 5. Aug. 2013 (CEST)

Aufzählungszeichen und Bild auf der linken Seite

Bei meinem Internet Explorer (Version 9, 64-bit Edition) funktioniert die Kombination von Aufzählungszeichen und einem Bild auf der linken Seite nicht (wie zum Beispiel in Piz Forbesch) (Der Fehler wurde im Artikel mit einem Workaround behoben, er kann jedoch noch hier nachvollzogen werden). Die Aufzählungszeichen werden links vom Bild angezeigt, der Text steht richtigerweise rechts. Bei Firefox ist alles so wie es sein sollte. --Capricorn4049 (Diskussion) 16:11, 7. Aug. 2013 (CEST)

Der Opera-Webbrowser hat das selbe Problem. Eine elegante Lösung (etwa zentral per Common.css) gibt es dafür nicht. Am einfachsten ist es, die Bilder anders zu positionieren, beispielsweise als Galerie. Zur Not kann man in äußersten Ausnahmefällen auch mal mit unsichtbaren Layouttabellen oder wenn man sich auskennt auch mit so etwas wie <div style="overflow:hidden;">…</div> um die Liste arbeiten. In dem Beispiel, in dem die zwei Bilder und die Liste inhaltlich eng zusammen gehören, erscheint mir eine Tabelle tatsächlich zweckmäßig. --TMg 14:43, 19. Aug. 2013 (CEST)
Ok, vielen Dank. Mit Tabellen funktionierts natürlich (zumindest auf IE). Habe es im Artikel Piz Forbesch angepasst. Falls doch noch jemand den Fehler nachvollziehen will, kann er dies hier tun. --Capricorn4049 (Diskussion) 14:58, 20. Aug. 2013 (CEST)

Idee zur Vermeidung von reinen Sperrprüfungsaccounts

Moin, beim Betrachten der letzten Änderungen kam mir soeben der Gedanke, ob es nicht möglich wäre, bei Benutzersperrungen eine Bearbeitung der Sperrprüfungsseite standardmäßig weiterhin zuzulassen. Der Vorgang der Sperrprüfung könnte so wesentlich vereinfacht werden, da das umständliche Anlegen eines neuen Kontos und das Erfordernis, dieses zu bestätigen, entfielen. Vor allem würde das Benutzerverzeichnis so auch von den Sperrprüfungs-Karteileichen entlastet. Technisch sollte das wohl möglich sein, immerhin bleibt die Benutzerdiskussionsseite ja normalerweise auch frei. Meinungen? Grüßle, --Björn 19:07, 28. Aug. 2013 (CEST)

Weiß nicht, ob das technisch so ohne weiteres umsetzbar wäre, aber prinzipiell natürlich wünschenswert. Work around wäre, dass jeder Benutzer eh ein zweites bestätigtes Konto hat, das während der Sperre des Hauptkontos nur zu Sperrprüfungszwecken benutzt werden darf. Den tieferen Sinn des ständigen Sperrens von SPP-Konten hab ich ehrlich gesagt noch nicht so richtig verstanden. Gruß, --NoCultureIcons (Diskussion) 19:52, 28. Aug. 2013 (CEST)