Ich habe eine Extension erweitert und zur Gruppierung von Personen eine Auswahl-Möglichkeit konfiguriert.
Diese Auswahl-Möglichkeiten sind jeweils auf 4 Sprachen übersetzt und stehen in einer eigenen Tabelle.
Im Backend werden mir jetzt alle Sprachen, inklusive deren Übersetzungen angezeigt und bei meiner Abfrage muss ich dementsprechend auch alle einzlenen uid's der Datensätze abfragen. (obwohl es sich ja eigentlich um das gleiche handelt)
Vielleicht erleichtert euch der Screenshot das Verständnis für mein Problem.
Bild: bilder-hochladen.net/…/6t08-1.gif
Kann ich das irgendwie anders lösen?
Ziel wäre es das mir im Backend nur die jeweiligen Übersetzungen für die eingestellte Backend-Sprache angezeigt werden und im Frontend dementsprechend sprachübergreifend Ergebnisse geliefert werden.
Keiner eine Idee, oder versteht man mein Problem nicht?
Hab mal bei einer anderen Extension abgeschaut und dort funkioniert es - aber ich konnte nicht nachvollziehen wie es programmiert ist. Irgendwie muss es ja in den Dateien ext_tables.php oder dem tca.php verewigt sein, da es ja eine Backend-Einstellung ist.
Wäre wirklich sehr dankbar für Hilfestellungen.
Okey ... einmal mehr habe ich es nach langer Suche selber herausgefunden.
Hatte da TYPO3 wohl ein bisschen überschätzt. o.O
Damit die Anzeige im Backend nur die die Datensätze der Hauptsprache darstellt muss in der tca.php oder in der ext_tables.php die SQL-Abfrage erweitert werden.
In meinem Fall war es die ext_tables.php, da ich ja eine bestehende Extension erweitert habe. Einfach den Config-Abschnitt "foreign_table_where" um die Angabe der "sys_language_uid" erweitern.
"foreign_table_where" => "AND tx_table.sys_language_uid = 0 ORDER BY tx_table.uid",
Für die programmierte Ausgabe meiner Extension musste ich mir danach etwas anderes einfallen lassen, damit auch die Auswahl auch die Datensätze sucht die einer "übersetzten" Kategorie angehören.
Problem solved!
Mal wieder eine späte Antwort.
Bin vor einem ähnlichen Problem gestanden.
Folgende Lösung (http://typo3-blog.net/tutorials/news/22-tuerchen-bei-mehrsprachigkeit-standartsprache-im-typo3-backend-bennen.html) finde ich aber etwas komfortabler, da sys_language_uid nicht fest belegt ist und nur Datensätze der selben Sprache angezeigt werden.
...
"foreign_table_where" => "AND (sys_language_uid=CAST('###REC_FIELD_sys_language_uid###' AS UNSIGNED) OR sys_language_uid= -1)"
...
Viele Grüße.
Hallo,
ich stehe gerade vor demselben Problem. Die Abfrage funktioniert zwar in soweit, dass dann im Backend "deutsch", "englisch" usw. in der richtigen Lokalisierung angezeigt wird, dummerweise speichert er dann aber dann nicht die UID des ursprünglichen Elements (=l10n_parent) in die Datenbank, sondern die UID der Übersetzung. Ich habe bisher leider in der Dokumentation noch keine Einstellung gefunden, wie man das beeinflussen könnte.
Habt ihr eine Idee?
Schönen Abend
Andreas
Kommt zwar zu spät aber vielleicht landet jemand anders so wie ich auch hier.
Ich stand grad vor einem ähnlichen Problem und wollte mir nur die Datensätze in der Selectbox anzeigen lassen die die gleiche Sprache haben wie der Datensatz der gerade beabeitet wird.
Ich hab das TCA so geändert:
'foreign_table_where' => 'AND (tx_beispiel.sys_language_uid = ###REC_FIELD_sys_language_uid### OR tx_beispiel.sys_language_uid = -1)',
Ich möchte diesen Thread nochmals aufgreifen. Was hier beschrieben wird, ist ein generelles "Problem/Feature" von TYPO3. Übersetze ich ein Inhaltselement, muss auch die Relation zu einem weiteren Element angepasst werden, nämlich auf den ebenfalls lokalisierten Datensatz.
Wie gehe ich sinnvollerweise vor, wenn alle Elemente ohnehin 1:1 übersetzt werden sollen - sprich ich lege 1x die Lokalisierung des Basis-Inhaltselements an - die Relationen werden wie alle anderen Attribute auch aus dem Basiselement übernommen - fertig. Die Übersetzung im Frontend sollte von TYPO3 übernommen werden. Das heißt natürlich, dass ich keinerlei Unterschiedliche Relationen in den verschiedenen Sprachen haben kann.
Klassischer Fall: Produkt und Produktkategorie. Ein übersetztes Produkt übernimmt die Relation zur Kategorie in Standardsprache (Relation in allen Sprachen gleich). Im Frontend wird jedoch die Kategorie wiederum übersetzt ausgegeben.
Hat jemand eine Lösung?
@paillon6 Exakt dieses Problem habe ich auch. Dieses verschärft sich dann besonders bei einer hohen Anzahl von Datensätzen.
Den einzigen Lösungsansatz den ich mir gerade vorstellen kann ist, dass ich die Relationen von Übersetzungen also von allen Einträgen, die nicht in der Standardsprache verfasst sind automatisch synchronisiere. Also wenn immer ein Eintrag in der Standardsprache gespeichert wird, die Relationen all seiner Übersetzungen die selben übersetzten Relationen erhalten. Ähnliches wenn ich eine Übersetzung speichere, nur dass dann auf den ln10_parent zurückgegriffen wird. Das Ganze würde dann über die Hooks im Backend laufen. Allerdings habe ich dann natürlich ein Problem, wenn zu einer Relation keine passende Übersetzung existiert.
Weiter Frage ich mich ob nicht irgendwer sich schon mal die Mühe gemacht hat, zu diesem Thema einen Artikel zu verfassen?
@paillon6 Wenn ich das richtig verstehe willst du die Relationen immer aus dem ursprünglichen Datensatz in der Standardsprache verwenden; zumindest ist das bei mir der Fall. Ich verwende daher nun die Option `ln10_mode` mit `exclude`. Damit wird das entsprechende Feld in der Übersetzung nicht angezeigt. Allerdings musst man sich dann im Frontend darum kümmern, das die Übersetzung korrekt stattfindet. 😉