glueckpress/stringintelligenz

[Discontinued] Inclusive WordPress localization

stringintelligenz's Issues

String-Update WordPress 4.7

Für WordPress 4.7 importieren wir die Core-Übersetzung erneut und veröffentlichen eine 0.2.1.

Inline documentation

Instead of line comments for properties, one better use real DocBlock comments.

On-Boarding

Menschen, die das Plugin aktivieren, sollten wir pro-aktiv abholen. Dafür gibt es 2 relevante Szenarien:

Unterstützte Locale

• Das Plugin wurde aktiviert, die Locale wird unterstützt, es sind also Änderungen im UI sichtbar.
• $user sieht anstelle des üblichen Plugin aktiviert eine Erfolgsnachricht mit kurzen Tipps zu sichtbaren Änderungen, sowie Channels für Feedback und Support.
• Die Notice braucht nicht lokalisierbar zu sein, weil sie eh nur erscheint, wenn das ganze Backend auf Deutsch angezeigt wird.
• Die Notice kann weggeklickt werden und bleibt dann weg.

Nicht unterstützte Locale (inklusive anderer Locales als Deutsch)

• Das Plugin wurde aktiviert, die Locale wird nicht unterstützt, es sind keine Änderungen im UI sichtbar.
• $user sieht zusätzlich zum üblichen Plugin aktiviert eine Warnung mit Tipps zum Wechseln der Locale im Backend (Einstellungen→Allgemein).
• Die Notice ist lokalisierbar; default ist Englisch (wie WP selbst).
• Die Notice kann weggeklickt werden und bleibt dann weg.

Autor

Für Author brauchen wir einen einzigen, in den verschiedensten Zusammenhängen funktionierenden, gender-neutralen Alternativ-Begriff zu Autor.
Oder eine andere Endung.
Oder Beidnennung: Autor/Autorin

https://wordpress.org/support/topic/author-ohne-kontext/

Für 0.2.0 schauen wir uns mal die Beidnennung an: Autor/Autorin

Semantic Versioning

Since the plugin is not yet officially released, nor submitted to wordpress.org, it's quite easy to switch to Semantic Versioning (instead of arbitrary versioning).

Version numbers then would have to be of the form X.Y.Z, with a possible suffix. Depending on what types of changes are included in a new release (compared to the previous/latest), it is clear what the new version number has to be.

Vereinheitlichung der Groß- und Kleinschreibung der Anrede

In den Texten gibt es unterschiedliche Schreibweisen der Groß- und Kleinschreibung der Anrede. Beispiel:

Im Hilfe Tab beim Permalink-Setup: "Ein Permalink ist die Webadresse, die zu Deinem Inhalt verlinkt." und weiter unten "Auf dieser Seite kannst du deine gewünschte Permalinkstruktur einstellen."

Wir sollten hier eine Einheitlichkeit einführen. Ich persönlich finde das Kleingeschriebene am angenehmsten zu lesen.

Separate construction from initialization

In the current code, the constructor does too much work. I suggest to separate the actual construction of the class instance from initializing the object (i.e., hooking up methods).

If you're interested in that, I can provide a PR including an optimized class.

Typos und fehlende Satzzeichen

"User deleted." > "Profil gelöscht"

Fehlt der Punkt 🙂

Support other locales

In order to support other locales, the following needs to be implemented:

• Check if mo files exist for the current locale or user locale. If so, pull them in; if not, bail with user notice.
• Add i18n for success admin notice (was only German before).
• update shipped de_DE core translations
• update contextual material (readmes etc.)

Update: see commit description 1ccede7

Aktuelle Strings von 4.6.x mergen

Bevor 4.7 kommt, sollten die Strings für 4.6.x noch einmal importiert werden.

Unterstützung von User Admin Language in WordPress 4.7

Bisher (Version 0.2.0) arbeitet Stringintelligenz mit der Site Locale de_DE. Wenn diese nicht gesetzt ist, reagiert das Plugin mit einer Warnung im UI und stoppt die weitere Ausführung:

if ( 'de_DE' !== get_locale() ) {
	add_action( 'admin_notices', array( new StringintelligenzAdminNotice(
		$this->templates_folder . '/admin-notice-locale-not-supported.php'
	), 'render' ) );

	return;
}

In WordPress 4.7 gibt es das neue Feature der User Admin Language. Da es sich bei Stringintelligenz um die Sprache im UI dreht, scheint die Erwartung legitim, dass die User Locale unterstützt werden sollte und das Plugin auch dann einwandfrei funktioniert, wenn de_DE als User Locale gesetzt ist, die Site Locale aber ggf. eine andere ist.

Die Bedingung für das Anzeigen einer „Nicht-unterstützt“-Nachricht und für den Stopp der weiteren Ausführung sollte also die neue User Locale mit einbeziehen:

$user_id = get_current_user_id();
if ( 'de_DE' !== get_locale() || 'de_DE' !== get_user_locale( $user_id )  ) {
    // s.o.
}

⚠️ Leider stehen WP_User bzw. Funktionen wie get_user_locale() während der gegenwärtigen Abfrage noch nicht zur Verfügung; bei einem Dump werden Fallback-Werte geliefert:

Current user ID: 0
Current user locale: en_US

Die Ergänzung der if-Abfrage um get_user_locale() scheint also an ihrer momentanen Position in Stringintelligenz::initialize() nicht möglich.

@tfrommen, wie würdest du das architektonisch lösen?

Rollenbezeichnungen

Wir sollten mit Rollenbezeichnungen experimentieren, die sich auf Berechtigungen beziehen – nicht nur wegen des Dramas um Gender-Sterne, sondern generell, um testen, wie Nutzer*innen damit zurecht kommen.

Siehe Vorschläge in diesem Topic: https://wordpress.org/support/topic/rollenbezeichnungen/

Zum Beispiel:

alt	neu
Administrator	Administrative Rechte
Redakteur	Redaktionsrechte
Autor	Schreibrechte
Mitarbeiter	Eingeschränkte Schreibrechte
Abonnent	Leserechte
Keine Rolle	Keine Rechte

Rollenbezeichnungen abstrakt und nicht stringent

Die aktuelle Beschreibung der Rollen wirkt auf mich nicht durchgängig und erschwert IMHO das Verständnis, weil zwischen einer abstrakten Rollenbezeichnung (Mitglied) und einem abstrakten Ablauf der Beitragserstellung (Entwürfe, Inhalte, Redaktion, Administration) gewechselt wird.

Die Originalübersetzung verwendet für die Rollenbezeichnungen Aufgabenbeschreibungen aus dem Zeitungswesen: Subscriber, Contributor, Author, Editor und Administrator. Dies drückt vor allem die Tätigkeiten der Beteiligten aus. Als geschlechtsneutrale Übersetzung würde sich deshalb aus meiner Sicht eine substantivierte Tätigkeit besser eignen:

Original	Übersetzung
Subscriber	Abonnieren
Contributor	Entwerfen
Author	Veröffentlichen
Editor	Herausgeben
Administrator	Administrieren*

(* Die Tätigkeit des Administrators lässt sich zwar auch ohne Verwendung eines Fremdworts mit Verwalten umschreiben, drückt dann aber nicht den Umfang der Berechtigung aus. Der Begriff der Administration hat bei Computerprogrammen eine besondere Bedeutung, die aus der Übersetzung hervorgehen sollte.)

Die substantivierten Tätigkeiten verdeutlichen die Aufgabenverteilung bei der gemeinschaftlichen Arbeit an einem Blog/einer Website ("was darf ich?") und passen gut in den Kontext der Menüs im WordPress Backend ("Standardrolle eines neuen Profils: Abonnieren – Entwerfen – Veröffentlichen – Herausgeben – Administrieren", bzw. "Rolle: …").

Probleme mit WordPress 4.9.6

Mir ist aufgefallen, daß neuerdings Settings im Backend so stehen bleibt (statt Einstellungen). Ob das ganze wirklich erst mit WordPress 4.9.6 aufgetreten ist, kann ich nicht beschwören, aber zumindes bräuchte das Plugin offenbar einmal ein Update.

„Zugangsname“ im Kontext „Profil“ durch „Profilname“ ersetzen

Im Kontext Profil sollte nicht vom Zugangsnamen, sondern vom Profilnamen die Rede sein.
Danke, @pixolin!