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
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
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".
