Hallo Johannes
ich denke, das Umschreiben der RevierUID von 8 auf 3 ist etwas, was
nicht automatisch passiert, weil es wohl etwas zu komplex ist.
Das ist auch was, was der Core selber müsste erledigen können und das
tut und tat er bisher nicht. Wohl auch wegen der Fallback Problematik.
Wohl müsste man mal mit den Core-Entwicklern diskutieren, wer für solche
Funktionalität zuständig ist und dann mit den richtigen Personen ein
Konzept erstellen, welches diese Funktionalität zur Verfügung stellt.
Und dann bräuchte es sicher noch Sponsoren um das ganze umzusetzen.
Liebe Grüsse
Renzo
-- 
conPassione gmbh
CH-3661 Uetendorf
+41 33 345 00 92 

Am Dienstag, den 03.06.2014, 02:02 +0200 schrieb Johannes C. Laxander:

> Lieber Renzo,
> 
> vielen Dank für die Mühe die du dir mit der Erläuterung gegeben hast.
> 
> Zuerst muss ich noch eine Richtigstellung machen:
> es handelt sich in meinem Beispiel natürlich um eine n:1-Relation!
> Ich denke das ging aus dem Beispiel auch hervor.
> 
> > Das Problem ist, dass beim Übersetzen im Relationsfeld des Datensatzes
> > EnglishA immer noch die ID=101 von DetailDeutschB steht, anstatt 102 von
> > DetailEnglishB.
> 
> Ja, das ist so. Und m.E. ist das auch der Fehler.
> Ich habe mal folgendes Beispiel gemacht, um aufzuzeigen wie es sich aus 
> meiner Sicht verhält, und wie ich denke dass es gelöst werden könnte (müsste).
> 
> Tabelle "Törns"       
> uid Sprache title     RevierUID (n:1 Relation)
> 25  D       Törn 1    8 [Karibik]
> 26  E       Cruise 1  3 [Caribbean] (das wäre richtig)
> 26  E       Cruise 1  8 [Karibik]   (das ist das Ergebnis derzeit)
> 
> 
> Tabelle "Reviere"
> uid Sprache title     l10n_parent
> 8   D       Karibik   0
> 3   E       Caribbean 8
> 
> Meiner Meinung nach müsste beim Lokalisieren von Datensatz 25 nach Datensatz 
> 26 (= Kopieren) die Relation mit dem Fremdschlüssel (hier: 8) aus dem zu 
> lokalisierenden Datensatzes (hier: 25) über l10n_parent in der Kind-Tabelle 
> aufgelöst und revieruid im lokalisierten Datensatz entsprechend geändert 
> werden. Etwas vereinfacht ausgedrückt: 
> 
> 26.revieruid = SELECT uid FROM reviere WHERE sprache=E AND 
> l10_parent=revieruid
> 
> Aber warum ist das nicht so? Geht das so nicht oder habe ich bisher einfach 
> keinen Durchblick?
> Ich kann einfach nicht glauben, dass das nicht möglich sein soll. Bin mal auf 
> die Meinungen gespannt.
> 
> Gruß, Johannes.
> 
> > -----Ursprüngliche Nachricht-----
> > Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-
> > boun...@lists.typo3.org] Im Auftrag von Renzo Bauen
> > Gesendet: Montag, 2. Juni 2014 23:24
> > An: typo3-german@lists.typo3.org
> > Betreff: Re: [TYPO3-german] Datensätze einer 1:n-Beziehung lokalisieren
> > 
> > Lieber Johannes
> > 
> > ich habe es auch in den 4.x-er Versionen nicht geschafft, Relationen zu so 
> > zu
> > übersetzen, dass diese erhalten blieben.
> > 
> > Wohl ist das Problem, dass man dazu einen sehr komplizierten Mechanismus
> > bäuchte:
> > Datensatz DeutschA mit ID=1 hat eine Relation zu Datensatz DetailDeutschB 
> > mit
> > ID=101 Übersetze ich DeutschA mit ID=1 gibt dies einen Datensatz EnglishA 
> > mit
> > ID=2, DetailDeutschB wird zu DetailEnglishB mit ID=102 übersetzt.
> > 
> > Das Problem ist, dass beim Übersetzen im Relationsfeld des Datensatzes 
> > EnglishA
> > immer noch die ID=101 von DetailDeutschB steht, anstatt 102 von 
> > DetailEnglishB.
> > Dies automatisch zu tun ist sehr komplex, vor allem dann, wenn man noch das
> > Fallback berücksichtigen muss (Italienisch -> Französisch -> Englisch ->
> > Deutsch). Eine schnelle SQL-Query zu schreiben, die diese Daten liefert, 
> > ist sehr
> > komplex. Mit Versionen <4.7 habe ich dies nie getestet/verwendet und kann
> > deshalb nicht sagen, ob sowas überhaupt schon mal funktioniert hat. Ich 
> > weiss
> > einfach nur, dass es mit Extbase keine automatische Zuordnung dieser Art 
> > gibt.
> > Man muss deshalb den Übersetzern zumuten, bei der Übersetzung auch die
> > Relationen entsprechend anzupassen.
> > Der Grund für das Fehlen einer solchen automatischen Zuordnung wird wohl 
> > sein,
> > dass die dafür nötige Funktion sehr komplex und langsam wäre.
> > 
> > Eine andere Möglichkeit ist, die Detialdatensätze mit ((sys_language_id = 
> > 0) or
> > (sys_language_id=2)) für Englisch=2 zu suchen. Wird ein Datensatz übersetzt 
> > und
> > die Anpassung der Relation vergessen, dann hat er zumindest einen gültigen
> > Detaildatensatz. EnglishA zeigt damit auf DetailDeutschB was nicht optimal 
> > ist,
> > aber immerhin keinen Fehler auslöst.
> > 
> > Gruss Renzo
> > --
> > conPassione gmbh
> > CH-3661 Uetendorf
> > +41 33 345 00 92
> > 
> > 
> > _______________________________________________
> > TYPO3-german mailing list
> > TYPO3-german@lists.typo3.org <mailto:TYPO3-german@lists.typo3.org> 
> > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german@lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Antwort per Email an