ALT Tag für Bilder (Bildbeschreibung) nicht Sprachabhängig

[Radigewski]

Jörg schreibt doch, dass er 15 Auflösungen hat.

Das löst jedoch immer noch nicht das eigentliche Problem, wo man bei sprachunabhängigen Medien die sprachabhängigen ALT Texte pflegen sollte. Da hilft auch kein Remote-Media Projekt.

[JSydow]

Wahrscheinlich liegt die Lösung in der Antwort von Jascha Teichmann:
"Metadaten wäre dann für diesen Anwendungsfall schon das Stichwort "

Und ich schließe mich der Frage von Thomas an:
"Wie legt man denn ein sprachabhängiges Formularfeld in den Metadaten an?"

Ideale Lösung für uns:

1 Medium im Zielprojekt

"alt" Text je Sprache (gezogen aus den Projekteinstellungen) direkt am Medium pflegbar.

Danke und Grüße

Jörg

[teichmann]

Sprachabhängigkeit in den Metadaten ist leider tatschlich noch nicht möglich, da muss ich meine Aussage zurücknehmen, ich hatte an einen Workaround mit einer FS_LIST gedacht, bei der man manuell Sprachschalter einblenden lassen kann (show-language-tabs), diese werden jedoch in einer Metadatenvorlage ausgeblendet/deaktiviert.

Alternativ könnte man eine Sprachabhängigkeit in den Metadaten simulieren, z.B. mit Hilfe einer inline FS_LIST. Dafür legt man sich zunächst ein Absatztemplate mit einer Combobox, die man sich mit den im Projekt vorhandenen Sprachen befüllen lässt, und einem Textfeld für den alt-Text an.

Über die FS_LIST in der Metadatenvorlage erzeugt man dann pro Sprache einen Eintrag, oder man regelt das direkt über Vorgabewerte und lässt den Redakteur keine Einträge hinzufügen/löschen.

Auch nur ein Workaround, selbstverständlich keine optimale Lösung.

Zum Thema mehrsprachige Metadaten gibt es bereits einen laufenden Feature Request:

Mehrsprachige Metadaten

Gruß

Jascha

[JSydow]

Zusammenfassend kann man also sagen, das dies nur durch einen Workaround möglich ist.
Da das Thema "Barrierefreiheit" immer ein Thema ist, wäre die Mehrsprachigkeit der "alt" Texte was für ein zukünftiges Release.

Weiterhin habe ich gearde festgestellt das die "alt" Texte für mehrsprachige Bilder immer auf

alt="Special"

stehen obwohl eine Bildbeschreibung in der jeweiligen Sprache gepflegt ist.

[a_reg]

Auch wenn das Posting schon etwas älter ist, hier noch ein paar gedanken für eine alternative Umsetzung. Eine FS List mit Einträgen pro Sprache finde ich ehrlich gesagt (für den Nutzer) etwas umständlichen. Es "fühlt" sich irgendwie ungewohnt an da er ja eigentlich den Sprachreiter gewohnt ist um Mehrsprachigkeit zu pflegen. Sollte es sich nur um einige wenige Eingabenkomponenten handeln könnte man auch:

• im Metadatentemplate Gruppen definieren und als Tab mit 'DE' und 'EN' etc. bennen.
• pro (Server) Sprache dann je ein Textfeld in die Gruppe packen
• einen eigenen ValueService für Regeln implementieren. Dort kommt man über den LanguagAgent an alle Projektsprachen und kann überprüfen ob eine übergebene Sprache im Projekt zur verfügung steht.
• Die Sichtbarkeit jedes "Sprach" Tabs kann dann über eine Regel pro Tab gesteuert werden:

<SCHEDULE service="NameDesValueServices" id="1">

     <PARAM name="LANG"><TEXT>DE</TEXT></PARAM>           

</SCHEDULE>

<DO><PROPERTY source="#form.group_DE" name="VISIBLE"/></DO>

• Der ValueService muss nur true zurück liefern wenn 'DE' eine Projektsprache ist

Somit kann das Template alle möglichen Sprachen definiert werden und der Nutzer seinen Sprachreiter und zwar wie gewohnt lediglich für die Projektsprachen.

Das ganze lohnt sich denke ich jedoch nur für einige wenige Komponenten da der Wartungsaufwand bei Änderungn natürlich enorm steigt wenn man viele Sprachen abdecken muss.

Am besten weiter auf sprachabhängige Metadaten hoffen

[j_mueller]

Wir haben es auch genau so gelöst.

Es gibt in den Metadaten im Reiter "Medieninfos" Felder für die Bildbeschreibungen. Zum Beispiel "pt_alt_DE", "pt_alt_EN", ..., etc..

Zur Ausgabe gibt es eine Formatvorlage, der man das Medium, optional die gewünschte Sprache und sogar den Feldnamen "pt_alt" übergibt. Die Formatvorlage prüft dann, ob es ein Sprachabhängiges Feld ist, also ob es das Feld bzw. das Feld plus Suffix "_<LANG>" gibt.

Falls ja, liest sie den Wert aus. Ist der Wert leer, wird nochmal "_<MASTERLANG>" abgefragt.

Der Aufruf sieht dann in etwas so aus:

$CMS_RENDER(template:"get_meta_text", media:"someMedia", field:"pt_alt")$

Als Medium kann dabei ein String/Media/GraphicalMedium übergeben werden. In Kombination mit einem anderen Snippet, wird der Text entweder direkt ausgegeben oder bei Übergabe des Parameters "return" als Variable in den übergebenen Wert im Seiten- bzw. Absatz-Kontext geschrieben (also 'return:"myVar"' schreibt den Wert in 'myVar').

Zusätzlich haben wir eine Formatvorlage, die uns ein IMG-Tag rendert:

$CMS_RENDER(template:"img", media:[...])$

Rückblickend war das eine sehr gute Idee, ich kann nur jedem dazu raten es ähnlich zu machen. In dieses Template lässt sich dann z.B. das Meta-Text Template integrieren, damit Bilder immer mit Title und Alt Tag ausgegeben werden. Wir geben zusätzlich die FS-ID des Mediums als data-id mit aus, was die Rückwärtssuche nach Bildern in großen Projekten erleichtert und auch für JavaScript nützlich sein kann.

Auch globale Erweiterungen rund um Bilder (z.B. Nutzung eines CDNs und abweichenden (cookie-free) Domain-Namen) lassen sich damit gut umsetzen.

Eine Ausgabe könnte also so aussehen:

<img src="..." title="..." alt="..." data-id="..." />

Darüber hinaus haben wir aufbauend auf dieser Architektur ebenfalls Module zum Translation Import und Export implementiert. Damit lassen sich Bildunterschriften auch über Übersetzungsworkflows nutzen.

Funktioniert also alles sehr gut. Das nur als kleiner "Erfahrungsbericht".